Реферат - Андрияна Алексовска

ЮГОЗАПАДЕН УНИВЕРСИТЕТ "НЕОФИТ РИЛСКИ"
СПЕЦИАЛНОСТ “ИНФОРМАЦИОННИ СИСТЕМИ И ТЕХНОЛОГИИ”
________________________________________________________________________
РЕФЕРАТ
по
БАЗИ ОТ ДАННИ
Тема:
РЕЛАЦИОНЕН МОДЕЛ НА ДАННИ. ПРОЕКТИРАНЕ НА
РЕЛАЦИОННИ БАЗИ ОТ ДАННИ. НОРМАЛИЗАЦИЯ НА
РЕЛАЦИОННИ СХЕМИ.
Изготвила:
Факултетен № Име Презиме Фамилия
19251421003 Андрияна Алексовска
Проверил: __________________
/доц. д-р В. Кралев/
Благоевград, 2020
Релационен модел на данни. Проектиране на релационни бази от данни.
2
Нормализация на релационни схеми.
1. Увод
В този реферат ще говорим за релационният модел на бази данни, както и за

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

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

обединени от различни източници, например различни подобласти или
дейности на предметната област;
 общодостъпност – едни и същи данни, в едно и също време са достъпни за
различни потребители за разнообразни цели.
Андрияна Алексовска
19251421003
3
2. Аргументация
2.1. Модели на данните
2.1.1. Модели на данни
Фигура 1: Модели на бази данни
2.1.2. Сравнение на моделите на данни
Тенденциите сочат предимство на пазара на корпоративни системи за

хибридните обектно релационни СУБД.
Обектът в релационната СУБД 1се разбива на съставни елементи, които се

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

възможности за по ефективна и оптимизирана обработка.
1
СУБД – Системи за управление на бази от данни
19251421003
4
Релационни бази Обектно- релационни

Обектни бази данни
данни бази данни
ORACLE 7.x,
Informix Dynamic
ObjectStore, Gemstone,
Server,
ORACLE 8.x, Informix POET,
DB/2,
Производители и Universal Server, O2,
OpenIngres,
продукти Universal Server DB/2 , Versant,
Miscrosoft SQL
UniSQL Jasmine,
Server,
ODB-Jupiter
Sybase SQL
Anywhere
Модел на Релационен
Релационен модел Обектен модел
данните модел
Табличните
Съществено се
структури леко се
опростява разработката
възприемат и
Лекота в Аналогично на на приложни програми.
съществуват
разбиране и релационните бази Продукти за крайните
множество
използване данни потребители са
продукти за
създадени относително
крайните
малко.
потребители.
Множеството
Възможно е създаване
връзки води до Аналогично на
Данни със на сложни структури и
появата на голямо релационните бази
сложни връзки обмен на съобщения
количество данни
между обектите.
таблици.
Език за описание на
обектите и
Стандартен SQL2, заявките унифициран с
макар че всеки Език за манипулиране базов език за
производител на данните ObjectSQL, програмиране,
Език за заявки
предлага 100% съвместим с например, с C++,
специфични SQL2. Smalltalk, Java.
разширения. Допълнително се
предоставя език за
обектни заявки OQL,
Ядрата на Ядрата на обектно -
релационните релационните СУБД са Ядрата на обектните
Оптимизация СУБД са оптимизирани за работа СУБД са оптимизирани
ядра СУБД оптимизирани за с таблици и цели обекти за работа с обекти.
операции над от типа сложни данни.
таблици.
Таблица 1: Сравнение на моделите на бази данни
19251421003
5
2.2. Релационен модел на бази данни

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

релации (relations), е предложена от Едгар Код през 1970 година. За разлика от
ранните системи за бази от данни потребителите на релационните бази от данни
нямат нужда да са запознати с особеностите на организацията за съхраняване на
информацията на носителя. Заявките към такава база от данни се изразяват със
средствата на език от високо ниво, позволяващ значително да се повиши
ефективността на работата на програмиста.
Релационна схема RS се нарича множество Ω = {a1, …, an} от атрибути

(attributes; полета, колони, columns). Пример за релационна схема е
множеството от атрибути (StudentNumber, StudentName, Speciality).
Всеки атрибут ai има домейн, който означаваме с Dom(ai). Домейнът е

множеството от стойности, допустими за даден атрибут.
Кортеж (tuple; запис, ред, row) над схемата RS е последователност (v1, …,

vn), такава че vi ϵ Dom(ai) за всяко i = 1, …, n. За даден кортеж t означаваме
неговата стойност в атрибута ai с t(a i). Пример за кортеж е (17123, Иван Иванов
Иванов, Информатика).
Релация R над RS наричаме множество от кортежи над RS.
StudentNumber StudentName Speciality

17123 Иван Иванов Иванов Информатика
15321 Петър Иванов Петров Математика и информатика
13987 Иван Петров Георгиев Компютърни науки
17654 Георги Иванов Георгиев Информатика
Таблица 2: Пример за релация над релационната схема
Релационна база от данни наричаме множество от релации над

множество от релационни схеми, наречени с общото название схема на
базата от данни.
19251421003
6
2.2.2. Принципи на релационния модел

2.2.2.1. Възможности на релационния модел
2.2.2.1.1. Дефиниране на данни
 Дефиниране обектите, техните атрибути и връзки, които ще се използват в

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

таблица, съдържаща данните.
2.2.2.1.3. Контрол на данни
 Даване права за четене, актуализиране или въвеждане на данните.
 Създаване правила за ползване на данните от много потребители.
2.2.3. Релационни операции
Отношенията могат да бъдат базови или производни. В схемата на БД2,

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

атрибути. Релационния модел позволява да се създават различни видове
производни отношения.
2
БД – база от данни
19251421003
7
Производните отношения съществуват във вид на представяне (views) в

Microsoft SQL Server и заяви (queries) в механизма на СУБД Microsoft Jet. В
релационната теория масово се използва и за двата случая термина представяне.
Производните отношения се реализират чрез релационни операции. Те

служат за обновяване на БД и за извличане на информация, която отговаря на
задени условия.
2.2.3.2. Операции за обновяване на БД
 Въвеждане на нов кортеж;
 Изтриване;
 Модифициране.
2.2.3.3. Операции за извличане на данни

2.2.3.3.1. Релационна алгебра
Релационната алгебра представлява формален език, който илюстрира

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

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

групи: множествени операции и релационни опреации.
19251421003
8
2.2.3.3.2.1. Множествени операции
Използват се тъй като всяко отношение представлява по принцип множество

от кортежи.
 Обединение (union)
 Сечение (intersection)
 Разлика (differense)
 Декартово произведение (cartesian product)
2.2.3.3.2.2. Релационни операции
Разработени са специално за БД
 Селекция (select)
 Проекция (project)
 Съединение (join)
 Деление (division)
2.2.3.3.3. Съвременни езици
Поради голямата сложност на горепосочените езици, на тяхна база за

разработени практически ориентирани езици за обработка на данните в БД:
 Езици ориентирани към трансформация – представляват клас

непроцедурни езици, при които входните данни се преобразуват в
информация, като за целта се използват фиксирани структури за описание
на търсения резултат. Такива езици са: SQUARE, SEQUEL и производния му
език SQL.
 Графични езици – използват шаблони за заявки, които потребителят
попълва с примери, описващи необходимите резултати. Такъв език е Query-

by-Example,създаден първоначално от IBM и понастоящем реализиран в
СУБД Access.
19251421003
9
2.3. Проектиране на релационни бази от данни
При проектирането на база от данни се решават два основни проблема:
 По какъв начин да се изобразят обекти от предметната област в абстрактни

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

частта на физическото проектиране. Твърде много зависи от използваната СУБД.
Например, при работа със СУБД Ingres може да се избира един от предлаганите
способи за физическа организация на отношенията, при работа със System R
следва преди всичко да се помисли за клъстеризацията на отношенията и
необходимия набор индекси и т.н. Затова ще се ограничим с въпросите за
логическото проектиране на релационни бази от данни, които са съществени при
използването на всяка релационна СУБД.
Освен това, няма да засягаме много важния аспект на проектирането –

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

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

данни се състои в обоснованото вземане на решения за това,
 от какви отношения трябва да се състои БД и

 какви атрибути трябва да имат тези отношения.
2.3.1.1. Принципи за проектиране бази от данни

 Ефективно структуриране на информацията
Изключване на повтарящите се данни. Създаване на разпределени бази

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

Скоростта на работа зависи от СУБД, структурата на приложенията,
възможностите на компютрите на сървъра и клиента, както и от
характеристиките на мрежата.
 Осигуряване на възможност за разширение на базата с нови данни
Причини за разширение на базата данни се явяват ръстът на организациите,
новите потребителски изисквания, измененията на нормативни документи,
появата на нови приложения..
 Осигуряване на цялостност на данните
Базите данни трябва да съдържат само проверена информация.
Осъществява се с помощта на набор от правила, при нарушаването на които
се появява съобщение за грешка.
 Предотвратяване на несанкциониран достъп
Използват се средства за идентификация на потребителя—пароли, цифров
подпис и др.
 Предоставяне на ограничен достъп
Контролира се правото за достъп до информацията, като и правото за
промени в данните.
19251421003
11
 Облекчено създаване на приложения

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

реалния свят.
 Таблиците съхраняват данни за процесите и участниците в тях.
 Уникалността на записите в таблиците се гарантира чрез избор на първичен

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

единствено от идентификатора на обекта.
 Промяната на данните в един обект (без тези на идентификатора) не се

отразява на данните в другите обекти от модела.
2.3.1.3. Външни ключове и домени
Външен ключ - стойност която се явява поле /свойство/ за една таблица

и първичен ключ за друга таблица.
Слика 1: Външни ключове и домени
Външните ключове са основата за формиране на релационните връзки.
19251421003
12
Външните ключове трябва да са в една и съща област /домен/, със

съответстващите им първични ключове.
2.3.1.4. Релациони връзки

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

едно към едно, ако за всеки ред от едната
таблица има най много един ред в другата
Слика 2: Релация едно към едно таблица.
2.3.1.4.2. Релация едно към много
Проявява се когато една таблица има нула или много свързани “дъщерни”
записи в друга таблица.
В някои случаи едната страна на

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

множество редове във втората таблица и за всеки ред от втората таблица има
множество редове от първата таблица. Обикновено се реализира чрез създаване
на таблица за “връзка”, която да се идентифицира от съставен ключ, съдържащ
първичните ключове на двете таблици.
19251421003
13
2.4. Нормализация на релационни схеми
Процесът на проектиране на базата данни в съответствие с правилата,

дефинирани от д-р Код, се нарича нормализация на данните.
Д-р Код установява шест нива на нормализация, от които три са

базови. Нормализацията се изпълнява поетапно. Първите три стъпки са описани от
д-р Код в статията „По-нататъшна нормализация на релационните модели на
базите данни”.
Нормализацията е техника за структуриране на данните по начин, който

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

групират в таблици, а таблиците се групират в бази данни.
2.4.1. Задачи на нормализацията
Нормализацията изпълнява следните задачи:
 Изключване на повтаряща се информация в таблиците.
 Декомпозиция на един типов обект на няколко.
 Минимизиране на аномалиите при съхраняване, изтриване и промяна на
данните.
 Създаване на отворена към бъдещи промени структура.
 Създаване на структура, свеждаща до минимум влиянието на структурни
изменения върху вече създадени приложения.
19251421003
14
2.4.2. Стъпки за нормализация на данните
От показаната по-долу схема се вижда, че за да бъдат нормализирани

типовете обекти и съответстващите им таблици, те трябва да отговарят на
следните условия:
 Да бъдат плоски, т.е. да не съдържат повтарящи се групи атрибути (колони).
 Данните за всички неключови колони (атрибути) напълно да зависят от
значенията на първичния ключ.
 Всички колони (атрибути) да зависят от значенията на първичния ключ и да
не зависят един от друг.
Слика 4: Стъпки за нормализация на данните
19251421003
15
2.4.3. Нива на нормализация на данните

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

#заявкя #читател професия #книга
заявка читател книгата
1 2 3 4 5 6 7
00344 хххххххххххххх
245 22.01.99 0846 учител Иванов 01347 ссссссссс
13578 еееееееее
346 2502.99 0048 лекар Ванева 01237 уууууууу
Таблица 3: Ненормализирана релация
Тази релация е ненормализирана, защото допуска атрибутите в колони 5

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

Първичният ключ не е вече еднозначен, защото се среща повече от веднъж в
таблицата. Поради тази причина трябва да се образува съставен първичен ключ,
който се състои от частичните ключове— “# поръчка ” , “# читател” и # книга.
19251421003
16
# дата на #читател професия име на #книга име на

заявка заявка читател книгата
1 2 3 4 5 6
245 22.01.99 0846 учител Иванов 00344 хххххх
245 22.01.99 0846 учител Иванов 01347 ссссссс
245 22.01.99 0846 учител Иванов 13578 ееееее
346 25.02.99 0048 лекар Ванева 01237 ууууу
Таблица 4: Първа нормална форма
Новополучената релация “Поръчка” има недостатъци, известни като

аномалии при изтриване и промяна на данните.
Аномалия при изтриване на данни  ако се изтрие артикулът “Ванева”

от таблицата ще бъдат изтрити всички данни за поръчка 346
Аномалия при промяна на данни  ако променим номера на “Иванов”

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

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

съдържат атрибути, които са
функционално зависими не от
целия първичен ключ, а от части
от него, то за тях трябва да се
състави нова таблица. В нашия
случай заявените книги не
зависят еднозначно от първичния
Слика 5: Втора нормална форма
ключ, т.е на един ключ
съответстват няколко книги.
19251421003
17
2.4.3.4. Трета нормална форма
Слика 6: Трета нормална форма
Когато е във втора нормална форма и когато всеки атрибут не е транзитивно

зависим от първичния ключ.
2.4.4. Правила за запазване на целостността на данните
Целостността на данните е важно понятие за проектиране на базите от данни.

Има четири вида цялостност на данните:
 Цялостност на обект – едно от изискванията на проектирането на
релационна база от данни е възможността да се разграничат различните
екземпляри на дадено множество от обекти. Това понятие е известно като
цялостност на обект и се реализира чрез създаване на първичен ключ.
Според това правило за цялостност колоните, съставящи първичния ключ,
не могат да имат стойност NULL. Релационните бази от данни поддържат
специална стойност NULL, която указва неизвестните стойности (unknown).
 Цялостност на област – свързана е с осигуряване на валидност на
стойностите на колоните, т.е. да принадлежат на допустима област от
стойности. Реализира се с определяне на типа на колоните, допускане или
19251421003
18
не на стойност NULL, ограничения за валидност, стойност по подразбиране,

дефиниране на външен ключ.
 Цялостност на връзка – запазва дефинираните отношения (релационни
връзки) между таблиците, когато се въвеждат, променят или изтриват
редове. Целостността на връзките гарантира, че съществува съгласуваност
на стойностите на ключовете между таблиците – първичните и външните в
съответните таблици. Реализира се с дефиниране на ограничението външен
ключ. Когато се наложи цялостност на връзка, не се допускат следните
действия:
o да се добавят редове (или да се променят стойностите на колоните на
външния ключ) в една таблица, която е страната “много” на
релационната връзка, ако в първичната таблица, която е страната
“едно” на релационната връзка, липсва съответен ред.
o да се променят стойностите на колоните на първичния ключ в една
таблица, която е страната “едно” на релационната връзка, ако в
свързаната таблица (страната “много” на релационната връзка) има
поне един съответен ред.
o да се изтриват редове от една първична таблица, ако има свързани
редове в таблицата с външните ключове, т.е. страната “много” на
релационната връзка.
 Дефинирана от потребителя цялостност – дава възможност за
определянето на специфични бизнес правила, които не могат да се отнесат
към някоя от другите категории цялостност. Реализира се чрез създаване на
ограничения, съхранени процедури, функции и тригери.
19251421003
19
2.4.5. Крайни цели на процеса нормализацията
 Елиминиране на излишеството в данните.

 Избягване на аномалии при обновяването.
 Създаване на проект на базата, който отразява правилно предметната
област.
 Опростена и автоматична проверка на някои от ограниченията за
цялостност.
19251421003
20
3. Заключение
В заключение ще се подсетим на най-важните неща от реферата, но също ще

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

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

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

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

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

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

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

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

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

например за уеб сайт с две страници, до големи уеб или мобилни приложения,
блогове, онлайн магазини и други. Най-известните готови системи за управление
на съдържанието (CMS) поддържат и използват релационни бази данни -
WordPress, Joomla, Drupal, Magento и други. По-малко са тези обаче, които
поддържат не-релационни бази данни (като Drupal).
Базата данни се намира на един сървър. За да се разшири, може да се

увеличава мощта и ресурсите на този сървър. Възможно е релационната базата
данни да се разпростре на множество сървъри, но имплементацията обикновено е
сложна, ресурсоемка и времеемка. И тъй като тези бази не предлагат подобна
функционалност по естествен начин, допълнителна разработка ще е нужна, за да
може различните хардуерни точки да имитират работата на една база, на един
сървър. Допълнителни програмни разработки ще са нужни за управление на
логиката и дистрибутирането на заявките за данните между отделните точки, както
и за извличането и обединяването на данни от различните сървъри.
19251421003
22
4. Съдържание
1. Увод .............................................................................................................................................. 2
2. Аргументация ............................................................................................................................. 3
2.1. Модели на данните ........................................................................................................... 3
2.1.1. Модели на данни............................................................................................................ 3
2.1.2. Сравнение на моделите на данни............................................................................. 3
2.2. Релационен модел на бази данни ................................................................................ 5
2.2.1. Основни понятия ....................................................................................................... 5
2.2.2. Принципи на релационния модел......................................................................... 6
2.2.2.1. Възможности на релационния модел.............................................................. 6
2.2.2.1.1. Дефиниране на данни ....................................................................................... 6
2.2.2.1.2. Обработка на данни........................................................................................... 6
2.2.2.1.3. Контрол на данни ............................................................................................... 6
2.2.3. Релационни операции .............................................................................................. 6
2.2.3.1. Производно отношение ....................................................................................... 6
2.2.3.2. Операции за обновяване на БД ......................................................................... 7
2.2.3.3. Операции за извличане на данни...................................................................... 7
2.2.3.3.1. Релационна алгебра .......................................................................................... 7
2.2.3.3.2. Релационно смятане ......................................................................................... 7
2.2.3.3.2.1. Множествени операции .................................................................................... 8
2.2.3.3.2.2. Релационни операции ...................................................................................... 8
2.2.3.3.3. Съвременни езици............................................................................................. 8
2.3. Проектиране на релационни бази от данни............................................................... 9
2.3.1.1. Принципи за проектиране бази от данни ...................................................... 10
2.3.1.2. Таблици и уникалност ........................................................................................ 11
2.3.1.3. Външни ключове и домени............................................................................... 11
2.3.1.4. Релациони връзки ............................................................................................... 12
2.3.1.4.1. Релация едно към едно .................................................................................. 12
2.3.1.4.2. Релация едно към много................................................................................ 12
2.3.1.4.3. Релация много към много ............................................................................. 12
2.4. Нормализация на релационни схеми ........................................................................ 13
2.4.1. Задачи на нормализацията ....................................................................................... 13
19251421003
23
2.4.2. Стъпки за нормализация на данните ..................................................................... 14

2.4.3. Нива на нормализация на данните ......................................................................... 15
2.4.3.1. Ненормализирана релация ................................................................................... 15
2.4.3.2. Първа нормална форма ........................................................................................ 15
2.4.3.3. Втора нормална форма ......................................................................................... 16
2.4.3.4. Трета нормална форма .......................................................................................... 17
2.4.4. Правила за запазване на целостността на данните .......................................... 17
3. Заключение............................................................................................................................... 20
4. Съдържание ............................................................................................................................. 22
5. Библиография ......................................................................................................................... 24
19251421003
24
5. Библиография
Трифонова, Ц. Л. (2010). Бази от Данни. Велико Търново.
Трифонова, Ц. Л. (2012). Практикум по бази от данни . Велико Търново.
Тужаров, Х. (2007). Бази то Данни. Извлечено от Бази от Данни:

http://tuj.asenevtsi.com/DB2007/BD20.htm
19251421003

Реферат - Андрияна Алексовска

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Реферат - Андрияна Алексовска

Uploaded by

Copyright:

Available Formats

ЮГОЗАПАДЕН УНИВЕРСИТЕТ "НЕОФИТ РИЛСКИ"

СПЕЦИАЛНОСТ “ИНФОРМАЦИОННИ СИСТЕМИ И ТЕХНОЛОГИИ”

В този реферат ще говорим за релационният модел на бази данни, както и за

База от данни се нарича интегрирана съвкупност от взаимосвързани

 интегрираност – в базата от данни са събрани данни за предметна област,

Фигура 1: Модели на бази данни

2.1.2. Сравнение на моделите на данни

Тенденциите сочат предимство на пазара на корпоративни системи за

Обектът в релационната СУБД 1се разбива на съставни елементи, които се

Обектът в обектната СУБД се помества във вида в който е. Това създава

Релационни бази Обектно- релационни

Таблица 1: Сравнение на моделите на бази данни

2.2. Релационен модел на бази данни

Схемата за представяне на данните във вид на двумерни таблици, наречени

Релационна схема RS се нарича множество Ω = {a1, …, an} от атрибути

Всеки атрибут ai има домейн, който означаваме с Dom(ai). Домейнът е

Кортеж (tuple; запис, ред, row) над схемата RS е последователност (v1, …,

Релация R над RS наричаме множество от кортежи над RS.

StudentNumber StudentName Speciality

Релационна база от данни наричаме множество от релации над

2.2.2. Принципи на релационния модел

 Дефиниране обектите, техните атрибути и връзки, които ще се използват в

 Дефиниране типа на данните (числа, символи и други).

 Форматиране и валидизиране на данните.

2.2.2.1.2. Обработка на данни

 Филтриране или сортиране на избрани полета с данни.

 Обобщаване на данните по определени критерии.

 Актуализиране, изтриване, копиране в друга таблица или създаване на нова

2.2.2.1.3. Контрол на данни

 Даване права за четене, актуализиране или въвеждане на данните.

 Създаване правила за ползване на данните от много потребители.

2.2.3. Релационни операции

Отношенията могат да бъдат базови или производни. В схемата на БД2,

2.2.3.1. Производно отношение

Това е отношение, което се формира чрез други отношения, а не чрез

Производните отношения съществуват във вид на представяне (views) в

Производните отношения се реализират чрез релационни операции. Те

2.2.3.2. Операции за обновяване на БД

 Въвеждане на нов кортеж;

2.2.3.3. Операции за извличане на данни

Релационната алгебра представлява формален език, който илюстрира

2.2.3.3.2. Релационно смятане

Релационното сметяане представлява непроцедурен формален език,

Предложените от КОД операции на релационната алгебра се делят на две

2.2.3.3.2.1. Множествени операции

Използват се тъй като всяко отношение представлява по принцип множество

 Декартово произведение (cartesian product)

2.2.3.3.2.2. Релационни операции

2.2.3.3.3. Съвременни езици

Поради голямата сложност на горепосочените езици, на тяхна база за

 Езици ориентирани към трансформация – представляват клас

 Графични езици – използват шаблони за заявки, които потребителят

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

2.3. Проектиране на релационни бази от данни

При проектирането на база от данни се решават два основни проблема:

 По какъв начин да се изобразят обекти от предметната област в абстрактни

В случая на релационните бази от данни трудно се представят общи рецепти в

Освен това, няма да засягаме много важния аспект на проектирането –

повод в литературата, това е автоматическа проверка за непротиворечивост на

Така че ще смятаме, че проблемът за проектирането на релационна база от

 от какви отношения трябва да се състои БД и

2.3.1.1. Принципи за проектиране бази от данни

Изключване на повтарящите се данни. Създаване на разпределени бази

 Осигуряване на бърз достъп до базата данни