Тема 3 Система зберігання та обробки інформації як основи інформаційних систем, НУДПСУ

Тема 3. Система зберігання та обробки інформації, як основи інформаційних систем

На сьогоднішній день реляційні системи управління базами даних (РСУБД ) стали домінуючим типом програмного забезпечення для обробки даних. Щорічний об’єм продаж в цьому секторі ринку оцінюється у 8 – 10 мільярдів доларів (або 25 мільярдів доларів разом з інструментарієм для роробки), причому річний приріст цього об’єму складає 25%. Теперішнє програмне забезпечення є другим поколінням РСУБД, що базується на реляційній моделі даних, яку запрпонував Е.Ф.Кодд (E.F.Codd) в 1970 році.

В реляційній моделі всі дані логічно структуровані всередині відношень (таблиць). Кожна таблиця (далі замість терміну ‘відношення’ ми вживатимемо термін ‘таблиця’) унікальне ім’я і складається з поіменованих атрибутів (стовпчиків) ( в подальшому ми будемо вживати термін – стовпчик). Кожний рядок (кортеж) таблиці містить по одному значенню кожного атрибуту. Велика перевага реляційної моделі перед іншими полягає в простоті логічної структури. За цією простотою приховано серйозний теоретичний фундамент, якого не було у першого покоління СУБД (тобто у мережних і ієрархічних СУБД). В подальшому основну увагу ми сконцентруємо на вивченні реляційних систем управління базами даних (РСУБД).

Історія розвитку СУБД

Реляційна модель вперше була звпропонована Е.Ф.Коддом в 1970 році в його фундаментальній сатті ”Реляційна модель даних для великих сумісно використовуваних банків даних”. Нині публікація цієї статті вважається поворотним пунктом в історії розвитку систем баз даних, при цьому варто зауважити, що ще раніше була запропонована модель, що базувалась на теорії множин (Childs, 1968). Цілі створення реляційної моделі формулювались таким чином.

• Забезпечення більш вищого ступеню незалежності від даних. Прикладні програми не повинні залежать від зміни внутрішнього преставлення даних, в тому числі від зміни організації файлів, переупорядковування записів і шляхів доступу.

• Створення міцного фундаменту для вирішення проблем несуперечності і надлишковості даних. В статті Кодда вводиться поняття нормалізованих таблиць, тобто талиць без повторювання груп.

• Розширення мови управління данними операціями над множинами.

Запропонована реляційна модель була втілена в комерційному проекті, який розроблявся в кінці 70-х років в дослідницькій лабораторії корпорації IBM в Сан-Хосе, штат Каліфорнії, під керівництвом Астрахана (Astrahan). Була створерена система під назвою System R, прототип істинної реляційної РСУБД. Цей проект зарекомендував себе як дуже важливе джерело інформації про такі проблеми реалізації:

• як управління паралельністю;

• оптимізація запитів;

• управління транзакціями;

• забезпечення захисту і цілісності даних;

• технологія відновлення даних;

• врахування людського фактору;

• розробка користувацького інтерфейсу.

Виконання проекту стимулювало публікацію наукових статей з теорії реляційних баз і створення інших прототипів РСУБД. Розробка над цим проектом дала поштовх для створення мови структурованих запитів SQL (Structured Query Language) як засіб доступу до інформації з реляційної бази даних, також для створення комерційних РСУБД, які з’явилися на ринку на початку 80-х років ( SQL/DS і DB 2 фірми IBM, а також ORACLE фірми ORACLE Corporation). В 1986 році ANSI (Американський національний інститут стандартизації) зареєстрував перший стандарт на мову SQL, в якому зафіксовані команди мови. В 1987 році ANSI-стандарт SQL був прийнятий ISO (International Organization for Standardization – Міжнародна організація по стандартизації), як всесвітній стандарт. В 1992 році ANSI вніс корективи в стандарт 1986 року. Нині діє стандарт 1992 року, відомий як SQL-92. SQL є мовою реляційних баз даних, а не мовою системного програмування. ANSI SQL не містить ні засобів управління виконання програми (циклів, умовних перходів), ні засобів для створення форм і звітів.

SQL став єдиною мовою баз даних клієнт-сервер. Сервер бази даних (нижній рівень) відповідає за зберігання даних. Прикладні програми  (application) – клієнти (верхній рівень) добавляють або обновляють дані.

Другим проектом, який відіграв помітну роль в розробці реляціної моделі, був проект INGRES (INteractive GRaphics REtrieval System), робота над яким проводилась в Каліфорнійському університеті (місто Берклі) приблизно в той же час, що і   проект System R. Ці дослідження призвели до появи акдемічної версії INGRES, яка внесла значний вклад для загального визнання реляційної моделі даних. Пізніше, на основі даного проекту був створений комерційний продукт INGRES.

Третім проектом  була система Peterlee Relational Test Vehicle (Засіб для тестування відношень) наукового центру корпорації IBM розташованого в місті Петерлі (Великобританія). Цей проект був більш теоретичним ніж перших два. Його результати мали велике і навіть принципове значення для обробки запитів і їх оптимізації, а також для функціонального розширення системи.

Комерційні  системи на основі реляційної моделі даних почали з’являтись в кінці 70-х – на початку 80-х років. На сьогоднішній день існує декілька сотень різних реляційних СУБД як для мейнфреймів так для ПК, хоч багато з них не повністю задовольняють точному визначенню реляційної моделі даних. Розроблені на основі моделі Кодда реляційні бази даних стали стандартами в комп‘ютерній індустрії.

Реляційна модель даних

Реляційна модель базується на математичному понятті відношення, фізичним представленням якого є таблиця. Справа в тім, що Кодд, будучи досвідченим математиком, широко використовував математичну термінологію, особливо з теорії множин і математичної логіки. Пояснимо деякі терміни, які використовуються в реляційній моделі, а також основні структурні поняття.

Історично склалось так, що різними термінами позначаються одні і тіж поняття. Нижче наведена таблиця трьох варіантів термінів реляційної моделі.

Відношенення – це плоска таблиця, яка складається з рядків і стовпчиків.

Атрибут – це поіменований стовпчик відношення.

В реляційній моделі відношення використовуються для зберігання інформації про об’єкти, представлені в базі даних. Відношення мають вид двомірної таблиці, в якій рядки відповідають окремим записам, а стовпчики – атрибутам. При цьому атрибути можуть розташовуватись в любому порядку і незалежно від їх переупорядковування відношення буде залишатись одним і тим же, а тому матиме один і той же зміст. Приклад відношення АДРЕСНА_КНИГА наведено нижче. Уявімо собі телефонний довідник. Він містить множину рядків, кожен з яких відповідає певному індивідууму. Для кожного з них в ній представлені деякі незалежні дані, наприклад, номер телефону, адреса. Уявімо собі таку книгу у вигляді таблиці, яка містить рядки і стовпчики. Кожний рядок  відповідає певному індивідууму, кожний стовпчик містить значення певного типу даних: прізвище, номер телефону і адреса, - які є в кожному рядку. Телефонна  книга може  виглядіти таким чином:

Рис.1.Відношення “ АДРЕСНА_КНИГА”

Відношення АДРЕСНА_КНИГА має атрибути – Прізвище, Телефон, Адреса.

Домен – це набор допустимих значень для одного або декількох атрибутів.

Кожний атрибут реляційної бази даних визначається на деякому домені. Наприклад домен атрибуту Адреса відношення АДРЕСНА_КНИГА містить назви всіх вулиць м.Києва.

Кортеж – це рядок відношення.

Елементами відношення є кортежі або рядки таблиці. У відношенні АДРЕСНА_КНИГА кожний рядок містить 3 значення, по одному для кожного атрибуту.

Степінь відношення визначається числом атрибутів, які воно містить.

В нашому прикладі відношення “АДРЕСНА_КНИГА” має степінь 3.

Відношення з одним атрибутом має степінь 1 і називається унарним. Відношення з двома атрибутами називавється бінарним, з трьома – тернарним, а для відношеннь з більшою кількістю атрибутів використовується термін n-арний. Визначення степені відношення є частиною заголовка цього відношення.

Кардинальність відношенння – це кількість кортежів відношення.

В нашому прикладі відношення “АДРЕСНА_КНИГА” має кардинальність 3.

Реляційна база даних – це набір нормалізованих відношень.

Математичні відношення

Для більш глибшого розуміння суті терміну відношення розглянемо декілька математичних понять. Припустимо ми маємо дві множини - D₁,D₂ . Декартовим добутком цих двох множин (позначається як D₁ х D₂) є множина всіх можливих  пар (a,b) де а належить множині D₁ , b - D₂ . Записується це так

D= D₁ х D₂ ={(a,b)}, де a є D₁ , b є D₂

Приклад. Нехай D₁ ={2,4} i D₂ ={1,3,5}. Тоді D₁ х D₂ ={(2,1),(2,3),(2,5),(4,1),(4,3),(4,5)}.

Потужність декартового добутку 2 множин (кількість елементів) дорівнює добутку потужностей цих множин. Якщо через n позначити потужність множини D, через n₁ - потужність множини D₁ , через n₂ - потужність множини D_{2 ,} тоді

n=n₁ · n_{2 .}

Люба підмножина декартового добутку називається відношенням. Наприклад, підмножина {(2,1),(4,1)} множини D задає відношення R ={(2,1),(4,1)}.

Для визначення тих можливих пар, які належатимуть відношеннню, можна задавати деякі умови відбору. Наприклад, відношення R міститьпари, другий елемент яких дорівнює 1, тоді R можна задати таким чином:

R = {(a,b) | a є D₁ , b є D₂ i b=1}

На основі тих же множин можна задати друге відношення S , в яякому перший елемент в 2 рази більший другого. Отже

 S = {(a,b) | a є D₁ , b є D₂ i a=2b}

Зауважимо, що в нашому прикладі є тільки одна пара а саме –(2,1). Отже

S = {(2,1)}.

Зауважимо також, що множини D₁,D₂ і є доменами відношеннь R i S.  

Поняття відношення легко розповсюдити  m доменів. А саме декартовий добуток m доменів D₁,D₂, … , D_m визначається наступним чином

D₁xD₂x … xD_m ={(d₁,d₂, … ,d_m) | d₁ є D₁, d₂ є D₂, … , d_m є D_m}

Властивості відношеннь

Відношення повинні задовольняти таким вимогам:

• Відношення має і’мя, яке відрізняється від імен інших відношень (унікальність імені)

• Кожна клітинка відношення містить атомарне (неподільне) значення

• Кожний атрибут має унікальне і’мя

• Значення атрибуту беруться з одного і того ж домену

• Порядок розташування атрибутів не має ніякого значення

• Кожний кортеж є унікальним, тобто дублікатів кортежів не повинно бути

• Порядок розташування кортежів у відношенні не має значення

Для ілюстрації змісту цих вимог розглянемо відношення АДРЕСНА_КНИГА. Оскільки кожна клітинка повинна містити тільки одне значення, то недопускається зберігання в одній і тій же клітинці двох номерів телефонів одного і того індивідуума. Іншими словами, відношення не можуть містити повторювальних груп. Про відношення, яке має таку властивість, говорять, що воно нормалізоване і знаходиться в 1-й нормальній формі (1 НФ).

Імена стовпчиків відповідають іменам атрибутів відношення. Значення атрибуту Телефон беруться з домену Номери телефонів – множини номерів телефонів м.Києва. Недопускається розташування в цьому рядку інших значень, наприклад, поштових індексів. Стовпчики можна міняти місцями при умові, що атрибути переміщаються разом з його значеннями. Таким чином, таблиця буде представляти те ж відношення, якщо атрибут Телефон розташувати після атрибуту Адреса.

Значна частина властивостей відношень походить від властивостей математичних відношень.

• Оскільки відношення є множинами, то порядок елементів не має значення. Отже, порядок кортежів у відношенні неістотний.

• У множині елементи не повторюються. Аналогічно, відношення не містить кортежів-дублікатів.

• Кожний елемент в любому кортежі декартового добутку множин приймає єдине значення. Аналогічно, кожна клітинка відношення містить єдине значення.

Реляційні ключі

Необхідно мати можливість унікальної ідентифікації кожного оеремого кортежа відношення по значенню його атрибутів.

Суперключ – це атрибут або множина атрибутів, яка єдиним чином визначає кортеж даного відношення.

Потенційний ключ – це суперключ, який не містить підмножини атрибутів, яка також є суперключом.

Приклад. Нехай задано відношення R (kod,rik,kvartal,typ,sum), де атрибут kod задає ідентифікаційний код підприємства, атрибут rik задає рік, kvartal – квартал, typ – код податку, sum – відповідну суму податку. Множина всіх атрибутів а також множина K={kod,rik,kvartal,typ} є суперключами, множина K є потенційним ключом, а множина {rik,kvartal,typ} не є суперключем а отже і потенційним ключем.

Первинний ключ – це потенційний ключ, який вибрано для однозначного визначення кортежу всередині відношення.

Поскільки реляційні відношення не містять кортежів-дублікатів, завжди можна задати первинний ключ для даного відношення. В найгіршому випадку вся множина атрибутів може використовуватись як первинний ключ. В вище згаданому відношенні R множина атрибутів K є первинним ключем, причому єдиним.

Зовнішній ключ  – це первинний ключ, в якому один або більше атрибутів належить декільком відношенням.

Приклад. Нехай крім R визначено ще відношення Q (kod,name), де атрибут задає ідентифікаційний код підприємства, атрибут name – назву підприємства. Первинним ключем для Q, очевидно є множина атрибутів M={ kod }. Оскільки атрибут kod є і в K і M, то K є зовнішнім ключем.

Реляційна цілісність

Визначають два правила цілісності реляційної моделі – цілісність сутності і цілісність посилань. Перш ніж розглянути ці два правила, розглянемо поняття NULL.

NULL означає невизначеність. Тобто, якщо значення певного атрибуту невизначене, говорять, що цей атрибут приймає значення NULL.

Цілісність сутності означає, що первинний ключ відношення не містить значення NULL. Це стосується всіх відношень  бази даних.

Цілісність посилань означає, що якщо у відношенні існує зовнішній ключ, то значення зовнішнього ключа повинно відповідати значенню потенційного ключа деякого кортежу в базовому відношенні або приймати значення NULL. Пояснимо це на прикладі. Припустімо що значення атрибуту kod відношення R пробігає множину D₁ а значення атрибуту kod відношення Q – множину D₂. Тоді різниця множин D₁ \ D₂ має бути пустою.

Реляційна алгебра

Існує декілька варіантів набору операцій, які включають в реляційну алгебру. Спочатку Кодд запропонував 8 операторів, потім було доповнено ще декількома. Ми розглянемо 5 основних операцій реляціної алгебри, а саме виборка(selection), проекція(projection), декартів добуток (cartesian product), об’єднання (union) і різниця.На основі цих 5 можна вивести додатково операції з’єднання (join), перетину(intersection) і ділення (division). Операції виборки і проекції є унарними оскільки вони оперують з одним відношенням, а інші операції бінарні – вони оперуюють з двома відношеннями. Наведемо, скориставшись загальноприйнятими символічними позначеннями, неформальні визначення цих операцій.

Виборка. Результатом операції виборки s_{предикат} над відношенням  є знову відношення, яке містить лише ті кортежі, які задовольняють заданій умові (предикату). Предикат задає умову відбору на значення атрибутів відношення. Приклад операції виборки: s_B>1(U)=W, де W є таке відношення.

Проекція - Õ_{атр1, … ,атрN}(R) визначає нове відношення, що містить кортежі складені зі значень атрибутів атр1, … ,атрN і при цьому кортежі-дублі виключаються. Іншими словами, з таблиці, яка є представленням відношення R викидаються всі стовпчики, які не входять до списку атрибутів атр1, … ,атрN, потім з одержаної таблиці викидаються рядки-дублікати. Приклад: Õ_A,B(V) , Õ_A,B(L) матимуть вид:

О’бєднання. Операція об’єднання застосовується лише до відношень, які мають однакові множини атрибутів і однакові домени для відповідних атрибутів. Якщо це виконується, відношення називають сумісними по об’єднанню. Отже, якщо R i S сумісні по об’єднанню відношення, тобто мають одну і ту ж множину атрибутів A,  і мають можини кортежів I i J, то об’єднання Q=RÈSмаємножину атрибутів A і множину кортежів I È J. Нижче наведено приклад об’єднання відношеннь.

Перетин. Операція перетину застосовується лише до сумісних по об’єднанню  відношень. Отже, якщо R i S сумісні по об’єднанню відношення, тобто мають одну і ту ж множину атрибутів A,  і мають можини кортежів I i J, то перетин Q=RÇSмаємножину атрибутів A і множину кортежів I Ç J. Нижче наведено приклад перетину  відношеннь.

Різниця. Різниця R-S складається з кортежів відношення R яких немає у S. При цьому R і S сумісні по об’єднанню відношення. Можина кортежів R-S співпадає з теоретико-множинною різницею I \ J.

Декартів добуток. Якщо відношення R має  множину атрибутів А і множину кортежів I, відношення S – множину атрибутів B і множину кортежів J, тоді декартів добуток Rх S цих відношень матиме множину атрибутів АхB і множину кортежів IxJ.

Операції з’єднання

Нижче наведені різні типи операцій з’єднання, які дещо відрізняються одна від одної але корисні нв практиці.

• Тета-з’єднання (q-join)

• З’єднання по еквівалентності (equal-join), яке є частинним випадком тета-з’єднання

• Натуральне з’єднання (natural join)

• Зовнішнє з’єднання (outer join)

Тета-з’єднання (q-join). Операція тета-з’єднання відношень R µ_F S визначає відношення, яке містить кортежі з декартового добутку RxS, що задовольняють предикату F. Предикат F має вид R.a_i Ñ S.b_j де замість Ñ можна вказати один із операторів зрівнювання (<, <=, >, >=, =, -=).

З’єднання по еквівалентності (equal-join) – це тета-з’єднання предикат якого містить тільки оператором =. На рис.2 представлено відношення V, яке є з’єднанням по еквівалентності відношень T і  U.

Натуральне з’єднання (natural join) – це з’єднання по еквівалентності по всіх спільних атрибутах цих відношень.

Ліве зовнішнє з’єднання (left join). Лівим зовнішнім з’єднанням (left join) відношеннь R іS, називається з’єднання, в якому кортежі відношення R , які не мають однакових значень в спільних атрибутах відношення S, також включаються в результуюче відношення. Приклад лівого з’єднання показано на рис.1(відношення L) .

Нормалізовані відношення

При проектуванні бази даних в реляційній СУБД основною метою розробки логічної моделі даних є створення точного представлення данних, звязків між ними і необхідних обмежень. Для досягнення цієї мети необхідно перш за все визначить необхідний набір відношень. Метод, який використовують для вирішення цієї задачі, називається нормалізацією. Спочатку було запропоновано тільки 3 види  нормальних форм: перша (1НФ) , друга (2НФ) і третя (3НФ),які ми і розглянемо. Потім з’явились визначенння четвертої (4НФ) і п’ятої (5НФ). Слід зауважити, що на практиці 4 і 5 нормальні форми зустрічаються рідко.

Перша нормальна форма (1НФ). Відношення, в якому на перетині кожного рядка і кожного стовпчика міститься лише одне значення, знаходиться в 1НФ.

Друга нормальна форма (2НФ). Відношення, яке знаходиться в 1 НФ і кожний атрибут якого, що не входить в первинний ключ, повністю визначається первинним ключем.

Третя нормальна форма (3НФ). Транзитивна залежність. Якщо для атрибутів деякого відношення є залежності A ® B i B ® C, то говорять, що атрибут C транзитивно залежить від атрибуту A. Відношення, яке знаходиться в 1НФ і 2НФ і не мають атрибутів, що не входять в первинний ключ, які транзитивно залежали б від атрибутів з первинного ключа.

Реляційна модель звільняє користувача від взаємодії з фізичною структурою даних, їх розташуванням на фізичних носіях. Замість цього вона базується на логічних зв‘язках, які описуються з допомогою реляційної мови. Спочатку Кодд визначив 13 правил реляційної моделі. В подальшому Кодд розширив своє визначення реляційної моделі, які відомі як RM/V1 RM/V2 (реляційна модель версії 1 і версії 2). RM/V1 складається з 50 характеристик, а RM/V2 містить 333 характеристик.

Коли СУБД можна вважати реляційною

Існує декілька сотень СУБД для мейнфреймів і персональних комп’ютерів. Кожний розробник СУБД заявляє,що розроблена ним СУБД є реляційною. На превеликий жаль багато з них не є реляційними. Стурбований тим, що потенційні можливості реляційної моделі спотворюються, Кодд (Codd, 1985) запропонував 13 правил визначенння реляційних систем.

На протязі багатьох років запропоновані Коддом правила масу нарікань зі сторони спеціалістів. Одні заявляли, що ці правила є чисто теоретичними вправами, інші – що їх СУБД задовольняють багатьом цим правилам, яякщо не всім. Ці правила можна на 5 функціональних груп:

1. Фундаментальні правила.

2. Структурні правила.

3. Правила цілісності.

4. Правила управління данними.

5. Правила незалежності від даних.

Фундаментальні правила (правила 0 і 12)

Правило 0. Люба система, яка рекламується або представлається як реляційна СУБД повинна управляти базами даних виключно засобами її реляційних функцій.

Це правило означає, що СУБД не повинна використовувати не реляційні операції для виконанння таких видів робіт як визначення даних, маніпулюванння даними.

Правило 12. – правило заборони обхідних шляхів. Якщо реляціійна система має низькорівневу мову (з послідовною построчною обробкою), вона не може бути використана для відміни або обходу правил і обмежень цілісності, які сформульвані реляційною мовою      вищого рівня.

Це правило гарантує, що всі спроби доступу до даних контролює СУБД і цілісність бази даних не може бути порушена без відома користувача або адміністратора бази даних (АБД). Це не означає заборону використання мови низького рівня.

Структурні правила (правила 1 і 6)

Правило 1 – представлення інформації.Вся інформація в реляційній базі даних представляються в явному виді на логічному рівні і тільки одним способом – у вигляді значень в таблицях.

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

Правило 6 – поновлення представлень. Всі представлення, які є теоретично поновлюваними, повинні бути поновлюваними в даній системі. Зауважимо, що на сьогодніі ні одна система не підтримує цього правила.

Правила цілісності (правила 3 і 10)

Правило 3 – систематична обробка невизнаачених значень (NULL). Невизначене значення, яке задається з допомогою NULL, підтримується для систематичного представлення відсутньої або неприпустимої інформації.

Правило 10 – незалежність обмежень цілісності. Спеціфічна для даної РСУБД обмеження цілісності повинні визначатись мовою реляційних даних і зберігатись в системному каталозі, а не в прикладних програмах.

Правила маніпулювання даними (правила 2,4,5 і 7)

Ідеальна РСУБД повинна підтримувати 18 функцій управління даними. Вони визначають повноту мови запитів (тут термін “запит” включає і операцію вставки, поновлення і видалення).

Правило 2 – гарантований доступ. Для всіх і кожного елементу даних реляційної бази даних повинен бути гарантований доступ на основі комбінації імені таблиці, значення первинного ключа і значення імені стовпчика.

Правило 4 – динамічний інтерактивний каталог, побудований за правилами реляційної моделі. Опис бази даних повинен представлятись на логічному рівні таким же чином як і звичайні дані. Це дозволить користувачам використовувати для звертання до цього опису ту ж реляційну мову, що для даних.

Це правило вказує на те, що повинен існувати лише одна мова для маніпулування як даними так і метаданими.

Правило 5 – вичерпна мова даних. Реляційна система може підтримувати декілька мов і різні режими роботи з терміналами. Але повинна існувати по меншій мірі одна мова, оператори котрої реалізовували такі конструкції: 1) визначення даних; 2) визначення представлень; 3) команди маніпулювання даними (доступні як в інтерактивному режимі так і з програм); 4) обмеження ціліснсті; 5)авторизація користувачів; 6) організація транзакцій (запуск, фіксація, відкат).

Слід зауважити, що новий стандарт ISO для мови SQL забезпечує виконання всіх цих функцій.

Правило 7 – високорівневі операції вставки, поновлення і видалення. Здатність обробляти базові або похідні відношення (представлення) як єдиний операнд повинна відноситись не тільки до процедури виборки даних а і до операцій вставки, поновлення і видалення.

Правила незалежності від даних (правила 8,9 і 11)

Кодд визначає 3 правила незалежності даних від аплікацій, які використовують ці дані.

Правило 8 – фізична незалежність від даних. Прикладні програми і засоби роботи з терміналами повинні залишатись логічно незмінними при внесенні любих змін в способи зберігання даних або методи доступу до них.

Правило 9 – логічна незалежність від даних. Прикладні програми і засоби роботи з терміналами повинні залишатись логічно незмінними при внесенні в базові таблиціі любих змін, які теоретично не поввинні зачіпати прикладне програмне забезпечення.

Правило 11 – незалежність від розподілу даних. Мова маніпулювання даними в реляційній СУБД повинна дозволяти прикладним програмам і запитам залишатись логічно незміннними незалежно від того як зберігаються дані – фізично централізовано або в розподіленому виді.

Основні типи даних визначених стандартом ISO

В базах даних і мові SQL існує 6 скалярних типів даних, визначених стандартом ISO. Їх короткий опис наведено в таблиці. В деяких випадках   для спрощення маніпулювання і перетворення дані типу character i bit об’єднуються в один тип під загальною назвою “строкові типи даних”, а дані типів exact numeric i approximate numeric – під назвою “числові типи даних”. В подальшому ми використовуватимемо квадратні дужки для позначення необов’язкового елементу,наприклад, [a].

Символьні дані ( тип character)

Символьні дані - це послідовності символів з визначеного розробником СУБД набору символів.

Для визначенння даних символьного типу використовується такий формат:

CHARACTER [VARYING] [LENGTH]

CHARACTER може бути скорочено CHAR а CHARACTER VARYING до VARCHAR.

Наприклад, NAME char (20) – означає, що поле з назвою NAME має символьний формат з довжиною 20 byte. Зауважимо, що в кожному запису під поле NAME відведено 20 байт (фіксована довжина), а ADRESA VARCHAR(50) означає, що поле ADRESA має змінну довжину(максимум до 50 символів). Поле типу VARCHAR займає в пам‘яті рівно стільки місця, скільки необхідно для зберігання реального значення поля, але не більше зазначеного у визначенні числа (в наведеному прикладі – 50). Поля типу   VARCHAR можуть мати любу довжину, яка не перевищує деякого максимуму, визначеного в конкретній СУБД.

Бітові дані (тип bit )

BIT [VARYING] [length]

Наприклад, bit_str BIT(4) – означає, що в полі bit_str зберігається строка бітів фіксованої довжини 4.

Точні числові поля (Exact NUMERIC)

Тип точних числових даних використовується для чисел, які мають точне представлення в комп’ютері. Існує декілька способів визначення даних точного числового типу:

      NUMERIC [precision[,scale]]

      DECIMAL [precision[,scale]]

      INTEGER

      SMALLINT

Зауваження. INTEGER може бути скороченим до INT а DECIMAL до DEC, precision – кількість десяткових цифр числа, а scale – кількість десяткових цифр після коми.

Наприклад, d DECIMAL (8,4) означає, що поле d є числовим полем в якого 8 знаків (включно з крапкою) і 4 знаки після десяткової крапки. NUMERIC співпадає з DECIMAL.

INTEGER ціле число. SMALLINT – коротке ціле.

Наближені числові поля

FLOAT [precision]

REAL

DOUBLEPRECISION           

Параметр precision задає значність мантиси і залежить від конкретної реалізації.

FLOAT – число з плаваючою точкою, яке представлене в експоненціальній формі з основою 10. наприклад,  FLOAT (8).

REAL – співпадає з FLOAT, за виключенням того, що розмір не використовується.

DOUBLEPRECISION (або DOUBLE) – співпадає з REAL, хіба що точність для конкретної реалізації перевищує за REAL.

Дата і час (тип datetime)

DATE

TIME [time_precision] [with_time_zone]

TIMESTAMP [time_precision] [with_time_zone]

Тип даних DATE використовується для зберігання календарних дат (рік, місяць, число).

Тип даних TIME використовується для зберігання відміток часу (година, хвилина, секунда).

Тип даних TIMESTAMP використовується для сумісного зберігання календарних дат і відміток часу.

Формати представлення дат

Формат TIME

Завдяки формату визначеного для дат, над полями типу DATE можна виконувати арифметичні операції, зрівнювати їх.

Наприклад, до дати можна додати число і одержати нову дату. Різниця 2-х дат є число.

Багато розробників СУБД підтримують строки змінної довжини. Так званий VARCHAR тип.

Коротка характеристика сучасних СУБД     

На сьогоднішній день на інформаційному ринку присутні такі СУБД:

1. DB2. СУБД розроблена фірмою IBM. На сьогоднішній день ця СУБД сумарно зберігає і управляє найбільшим об‘ємом інформації.

2. ORACLE. Ця СУБД розроблена одноіменною фірмою ORACLE. Друга СУБД по сумарному об‘єму інформації.

3. MS SQL Server. Ця СУБД розроблена фірмою Microsoft і глибоко інтегрована в операційну систему Windows NT.

4. Sybase. Ця СУБД розроблена фірмою Sybase, слід зауважити, що до недавнього часу команди робітників фірми Sybase і фірми Microsoft працювали разом. Тому ці СУБД (Sybase і SQL Server) дуже схожі. Зараз ці команди працюють кожна над своїм проектом.

5. Інші СУБД до яких слід віднести такі: Interbase, Informix.

1) Вище згадані СУБД є СУБД клієнт-серверного типу. Що таке архітектура клієнт-сервер? В архітектурі клієнт-сервер множина ком‘ютерів об‘єднана в мережу, в якій всі комп‘ютери поділяються на клієнтів і серверів. Користувачі безпосередньо взаємодіють з клієнтами для виконання переважної кількості функцій. Сервери виконують різні інтенсивні завдання на запити клієнтів. СУБД, як правило, знаходиться на сервері і займається обслуговуванням вимог клієнтів. Вимоги клієнта до сервера формулюється на мові SQL. Оскільки мова SQL лаконічна, мережа не перевантажена передачею детальних інструкцій від клієнта до сервера. Одержавши команду SQL, сервер може виконувати цю команду без подальшої участі клієнта. В архітектурі клієнт/сервер важливим є питання про зв‘язки. Клієнт повинен бути зв‘язаним з сервером для взаємодії з ним.

2) Кожна з цих СУБД містить в собі систему ідентифікації і аутентифікації, тобто системи розподілу прав доступу до даних. Обробка інструкцій GRANT (призначення привілеїв доступу) і REVOKE (відміна привілеї).

3) Кожна з цих СУБД підтримує обробку транзакцій. Транзакція – це послідовність команд DML (Update, Insert, Delete), об‘єднаних в групу, які або виконуються всі, або не виконуються жодна. Помилка транзакції призводить до того, що вся послідовність може бути відмінена (Canceled), або для неї може бути виконаний відкат. Люба транзакція закінчується інструкцією COMMIT WORK (для того, щоб зберегти зміни), або інструкцію ROLLBACK (при відмові від внесених змін або у випадку збоїв в системі). Якщо транзакція не може бути відновлена з якихось причин, потрібно виконати її відкат.

4) Кожна з цих СУБД підтримує ведення журналу транзакцій.

5) Кожна з цих СУБД містить засоби для зберігання і виконання процедур і тригерів.

Крім вищезгаданих СУБД клієнт/серверного типу на інформаційному ринку функціонують локальні СУБД, які призначені функціонувати на ПЕОМ. Ці СУБД не підтримують ні транзакції, систему розподілу доступу, не ведуть для зберігання і обробки процедур і тригерів. До цього класу СУБД можна віднести такі:

1. dBASE (на ринку програмного забезпечення з 1983 року).

2. FoxBase, FoxPro.

3. Paradox.

4. Clipper.

5. Clarion.

6. MS Access.

СУБД цього класу мають одну характерну рису (крім MS Access) – кожна таблиця в таких базах є окремим файлом з тим же ім‘ям. Це означає, що крім засобів самої СУБД ми можемо скористатись засобами операційної системи для пергляду інформації з таблиць, змінювати інформацію в таблицях, і таке інше. Це є порушенням правил Кодда. Отже, ці СУБД не є реляційними. Вони не підтримують в повному обсязі мови SQL.

СУБД MS Access займає проміжне місце між локальними базами і базами клієнт/серверного типу.

Доступ до таблиць можливий лише засобами СУБД (всі таблиці базі зберігаються в одному файлі операційної системи з розширенням mdb). Є система ідентифікації, хоча вона реалізована засобами середовища Access, а не через мову SQL, як цього вимагає стандарт SQL-92.

З повагою ІЦ “KURSOVIKS”!