I. Основи на субд 2

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

Релационният модел (РМ) не е нещо статично. Той е развит през 1970 год. от д р E.F.Codd и се развива непрекъснато. В доклад за семинар, който се нарича “Релационен модел за данни за големи споделени информационни банки”, д р Код определя следните правила за модела на релационните бази данни:

1. 
   Релационните СУБД трябва да могат да управляват напълно базите данни с техните релационни възможности.
   
2. 
   Правило за информацията – цялата информация в дадена релационна база данни, включително имената на таблиците и колоните, се представят явно като стойности в таблиците.
   
3. 
   Гарантиран достъп – всяка стойност в релационните бази данни задължително трябва да е достъпна чрез име на таблица, име на колона и стойност на първичен ключ.
   
4. 
   Систематична поддръжка на нулеви стойности – СУБД трябва да осигури систематична поддръжка за нулевите стойности (непознати или неприложими данни), която е различна от стойностите по подразбиране и да е независима от който и да е домейн.
   
5. 
   Активен онлайн релационен каталог – описанието на базата данни и нейното съдържание се представя на логическо ниво като таблици и поради това тя може да бъде разпитвана чрез езика на базата данни.
   
6. 
   Пълен подезик за данните – поне един от поддържаните езици трябва да има добре дефиниран синтаксис и да бъде пълен. Той трябва да поддържа дефиниране на данни, манипулацията им, правила за интегритет на данните, упълномощаване и транзакции.
   
7. 
   Правила за обновяване на изгледите – всички изгледи, които са теоретично обновими, трябва да могат да се обновяват чрез системата.
   
8. 
   Вмъкване, обновяване и изтриване на ниво множество – СУБД трябва да поддържа не само извличането, но и вмъкването, обновяването и изтриването на информация на ниво множество.
   
9. 
   Физическа независимост на данните – да няма влияние върху логиката на приложенията, когато методите за физически достъп или структурите за съхранение на данните се променят.
   
10. 
    Логическа независимост на данните – доколкото е възможно не бива да има влияние върху логиката на приложенията, когато се правят промени в структурата на таблицата.
    
11. 
    Независимост на целостта на данните – езикът на базата данни трябва да може да дефинира правила за цялостност. Те трябва да бъдат записани в онлайн каталога и да не могат да бъдат заобикаляни.
    
12. 
    Независимост на дистрибуцията – приложенията и техните заявки не трябва да се влияят логически от това дали данните се разпространяват за първи път или се редистрибутират.
    
13. 
    Невъзможност за намеса – не трябва да има възможност да се заобикалят правилата за интегритет с помощта на езици от по-ниско ниво.
    

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

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

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

• 
  релационни обекти;
  
• 
  цялостност на данните;
  
• 
  релационни оператори за опериране с данните.
  

• 
  първоначално предложен от Chamberlin IBM;
  
• 
  прототип на езика под името System R - в лабораториите на IBM;
  
• 
  един от продуктите на IBM - IBM Database 2 или съкратено DB2 - и днес в системата OS/2 - 95 год.;
  
• 
  ANSDB - American National Standards Database Commitee - SQL стандартен език за релационни БД - релационен език.
  

1.Релационни обекти данни: Области (домейни)

1.1.Въвеждащ пример и основни понятия

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

Фигура 4-1 показва някои от най-важните понятия, използвани в примерна база данни за библиотека. Първо ще дадем неформална дефиниция на тези понятия, използвайки таблицата BOOK, съдържаща книгите в библиотеката.

1.1.1.Неформални определения:

• 
  релация (relation) - съответства на познатото ни понятие “таблица”;
  
• 
  подредено множество (tuple) - съответства на ред;
  
• 
  атрибут (attribute) - колона;
  
• 
  първичен ключ (primary key) - уникален идентификатор на таблица, т.е. поле (или комбинация от полета), който (която) притежава следното свойство: във всеки момент няма повече от един ред с една и съща стойност в това поле (комбинация);
  
• 
  област (domain) - множество от стойности, които могат да бъдат присвоявани като актуални стойности на атрибутите;
  
• 
  кардиналност – броят редове на релацията;
  
• 
  степен – броят колони (атрибути) на релацията.
  

Забележки:

• 
  еквивалентността на горепосочените понятия е приблизителна. По-късно ще покажем разликите между двете групи понятия;
  
• 
  понятието 'ключ' (key) е едно от най-добре разработените в областта на БД. Само в релационния модел различаваме 'първични' (primary), candidate, alternative, foreign ключове. В другите области на БД технологията се срещат index keys, hash keys, search keys, secondary keys, ordering keys, parent keys, child keys и много други. Ако се срещне понятието 'ключ' без допълнително пояснение, обаче, във всеки случай би трябвало да става въпрос за първичен ключ. Този вид ключове са най-важни в сравнение с всички други;
  
• 
  не всички релационни системи поддържат всички аспекти на релационния модел.
  

Някои изводи от примера:

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

1.1.2.Определение

Най-малката семантична единица данни (наричат се още скаларни) в релационния модел е индивидуална стойност на данни (ISBN номер на книга напр.). От гледна точка на релационния модел тези стойности са atomic, т.е. неделими.

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

Пример: областта на годините, в които са публикувани съответните книги - множество от цели числа между 1600 и 2004, т.е. в този диапазон стойността би имала смисъл, извън него годината на публикуване би била нереална.

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

1.1.3.Сравнения, ограничени върху областите:

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

1.1.4.Дефиниране на данните

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

Оператор CREATE DOMAIN domain data-type;

CREATE DOMAIN YEAR_PUB INT;

CREATE DOMAIN BOOK_TITLE VARCHAR(50);

CREATE BASE RELATION BOOK

( BOOK_ISBN VARCHAR(20) NOT NULL,

TITLE DOMAIN (BOOK_TITLE),

PRICE INT,

YEAR_PUBLISHED DOMAIN(YEAR_PUB)

);
Създавайки една нова област чрез CREATE DOMAIN ние караме СУБД да прави нова входна точка в системния каталог и да описва тази нова област.

CREATE BASE RELATION - включва референции към кореспондиращите области и създава нова входна точка в каталога на релациите.

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

1.1.5.Съставни области

Ще разгледаме съставните (composite) области. Една съставна област е дефинирана като Декартово произведение на множество от прости области.

Напр. съставната област DATE може да бъде дефинирана като Декартовия продукт на простите области MONTH, DAY, YEAR (в този порядък)

MONTH = (1,2,...,12)

DAY = (1,2,...,31)

YEAR = (00,01,...,99)
DATE = 1 1 00

1 2 00

...

1 31 00

....

12 31 99

или 12 * 31 * 100 = 37 200 елемента (разбира се не всички са валидни). Някой атрибут, дефиниран върху DATE-областта е съставен с компоненти, които са елементарни атрибути, дефинирани върху MONTH, DAY, YEAR области. Напр. (отново псевдо DDL)

CREATE DOMAIN MONTH CHAR(2);

CREATE DOMAIN DAY CHAR(2);

CREATE DOMAIN YEAR CHAR(2);

CREATE DOMAIN DATE (MONTH, DAY, YEAR);

CREATE TABLE EMPLOYEE

( EMP# ...... NOT NULL,

ENAME...... ,

HIREDATE DOMAIN ( DATE )

(HIREMONTH, HIREDAY, HIREYEAR),

DEPT#...... ,

SALARY..... );

DML операторите ще бъдат в състояние да се отнесат към съставния атрибут HIREDATE и елементарните HIREMONTH, HIREDAY, HIREYEAR. Напр.
SELECT *

FROM EMPLOYEE

WHERE HIREYEAR < '84';
SELECT *

FROM EMPLOYEE

WHERE HIREDATE = '010194';
Забележка: релационните нотации на областите са тясно свързани с нотациите за типове данни в програмните езици (предимно в модерните езици).
Pascal: type month = (1..12);

var hiremonth : month;

Този пример показва една “област” (т.е. тип данни) наречена MONTH и един атрибут (т.е. променлива), дефиниран върху тази област, наречен HIREMONTH.

1.1.6.Изтриване на области

DESTROY DOMAIN domain;

Изтрива областта от каталога.

Каталог: sites -> default -> files
files -> Образец №3 справка-декларация
files -> Р е п у б л и к а б ъ л г а р и я
files -> Отчет за разкопките на праисторическото селище в района на вуз до Стара Загора. Аор през 1981 г. ХХVІІ нац конф по археология в Михайловград, 1982
files -> Медии и преход възникване и развитие на централните всекидневници в българия след 1989 година
files -> Окръжен съд – смолян помагало на съдебния заседател
files -> Семинар на тема „Техники за управление на делата" 18 19 юни 2010 г. Хисар, Хотел „Аугуста спа" Приложение
files -> Чинция Бруно Елица Ненчева Директор Изпълнителен директор иче софия бкдмп приложения: програма
files -> 1. По пътя към паметник „1300 години България

Изтегляне 1.28 Mb.

Сподели с приятели: