Навігація
Головна
 
Головна arrow Інформатика arrow Бази даних
< Попередня   ЗМІСТ   Наступна >

Реляційні бази даних

Освоєння властивостей моделей даних (МД) ускладнюється тим, що в різних моделях даних використовується своя термінологія опису структурних елементів та їх зв'язків. Для спрощення вивчення МД нижче наведені відповідні терміни в порівнянні з поняттями, які у реляційної моделі даних.

Коротка характеристика структури моделей даних

Модель даних

Елемент структури

Зв'язок

Структура таблиці

Реляційна

Таблиці: стовпці - поля, рядки - записи

За ключу

Лінійна

Ієрархічна

Сегменти: вихідний і породжений - аналоги таблиць

По покажчику

Лінійна

Мережева

Записи: власник і член - аналоги таблиць

По покажчику і по ключу (зв'язок іменується); сукупність записів і зв'язок утворюють набір

Лінійна, нелінійна

Об'єктно-реляційна

Об'єкти (таблиці, абстрактні типи даних)

За ключу

Лінійна, нелінійна

Об'єктно-орієнтована

Класи об'єктів (типів даних, даних): об'єкт - рядок, стовпці - властивості (константи, вбудовані об'єкти, потоки даних, колекції, багатовимірні змінні, посилання)

За об'єктною посиланню і об'єктному вказівником

Лінійна, нелінійна

При обговоренні моделей даних (гл. 5-9) будемо дотримуватися такої однотипної послідовності;

  • 1) логічна структура, що включає опис структури (елементи, зв'язку);
  • 2) створення БД в рамках розглянутої моделі даних (МД);
  • 3) використання БД;
  • 4) властивості моделі даних (достоїнства і недоліки). Порівняльна таблиця властивостей МД приведена в гл. 9.

Логічна структура

Реляційні бази даних одержали широке поширення в персональних комп'ютерах. Найбільш відомі такі локальні СУБД, як dBASE, Paradox і особливо - Access. СУБД Oracle, Sybase, Informix, BTrieve, Ingress, InterBase були спочатку призначені для роботи в мережі з великими обсягами даних.

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

Домен - безліч значень (наприклад, безліч цілих чисел). Декартовим твором доменів D1, D2, .., Dk (позначається як D, × D2 × ... × Dk) називається множина всіх кортежів (V1, V2, ..., Vk) довжини до, таких, що Vi Î D1, i = I, I. Наприклад, якщо k = 2, DÎ = {0, 1} і D2 = {а, b, с}, то D1 × D2 є {(0, а), (0, b), ( 0, с), (1, а), (1, b), (1, с)), а ставленням може бути, наприклад, {(0, а), (О, с), (1, b)} .

Елементи відносини називаються кортежами і мають арность до (ступінь відносини), причому i-й компонентою є V1, Відношення зручно представляти таблицею - сукупністю всіх кортежів; кожен рядок є кортеж і кожен стовпець відповідає одному компоненту. Кортежі зазвичай нумеруються і їх кількість визначає розмірність таблиці. Стовпці називаються атрибутами, і їм часто присвоюються імена. Впорядкований список імен атрибутів відношення називається схемою відносини. Якщо відношення називається "Студент" і його схема має атрибути А1, А1, .... Аk, то таку схему будемо записувати як СТУДЕНТ (А1, А2, ..., Аk).

Сукупність схем відносин називається схемою (реляційної) БД, а поточні значення відповідних відносин - БД.

Дані з діаграми об'єктів-зв'язків уявляються двома видами відносин.

  • 1. Набір об'єктів може бути представлений ставленням, що містить всі атрибути даного набору об'єктів. Якщо об'єкти набору ідентифікуються за допомогою зв'язку з іншим об'єктом, то схема відносини містить додатково атрибути ключа другого набору.
  • 2. Зв'язок між наборами об'єктів Е1, Е2, Ек представляється відношенням, схема якого складається з атрибутів ключів кожного з цих наборів.

Реляційна модель є уявлення БД у вигляді сукупності впорядкованих нормалізованих відносин.

Для реляційних відносин характерні такі особливості.

  • 1. Будь-який тип запису містить тільки прості (за структурою) елементи даних.
  • 2. Порядок кортежів в таблиці неістотний.
  • 3. Впорядкування значущих атрибутів у кортежі повинно відповідати упорядкуванню атрибутів в реляційному відношенні.
  • 4. Будь-яке відношення повинно містити один або більше атрибутів, які разом складають унікальний первинний ключ.
  • 5. Якщо між двома реляційними відносинами існує залежність, то одне відношення є вихідним, друге - підлеглим.
  • 6. Щоб між двома реляційними відносинами існувала залежність, атрибути, службовці первинним ключем у вихідному відношенні, повинні також бути присутнім в підлеглому відношенні.

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

  • 1. Правило інформації. Вся інформація на логічному рівні представляється тільки значеннями в таблицях без використання покажчиків і індексів.
  • 2. Правило гарантованого доступу. Кожен атомарний елемент таблиці доступний через комбінацію з імені таблиці, імені поля і ключа.
  • 3. Системна підтримка Null-значень. Для представлення відсутніх даних з будь-яким типом використовують Νull-значення.
  • 4. Динамічний оперативний каталог на основі реляційної моделі. Метадані (словники) формуються тими ж мовами, що і дані.
  • 5. Правило вичерпного под'язика даних. У базі даних можливо використовувати кілька мов програмування, проте один (чаші всього - SQL) повинен бути головним.
  • 6. Правило поновлення подання (виду, View). Всі теоретично оновлювані подання може оновлювати і система.
  • 7. Введення, оновлення та видалення даних на високому рівні. Робота з декількома записами повинна бути характерна не тільки запитам на вибірку, але і запитам на оновлення.
  • 8. Фізична незалежність даних. Можлива зміна адреси БД, зміна фізичної компоновки БД не надаючи впливу на роботу прикладних програм і користувача.
  • 9. Логічна незалежність даних. При додаванні або видаленні елементів (таблиць, полів) у структурі БД інші частини бази даних залишаються незмінними.
  • 10. Незалежність цілісності. Ключ не повинен мати значення Null. Первинний і батьківський ключі повинні бути унікальними. Кожному значенню зовнішнього ключа повинно існувати значення батьківського ключа. Посилальна цілісність зменшує швидкодію через перевірки умов-зв'язків через словник.
  • 11. Незалежність розподілу. В розподіленої БД розташування даних незалежно. Для користувача така БД повинна виступати як централізована БД.
  • 12. Правило дотримання правил. Не можна обходити обмеження, введені за допомогою мови SQL.

Приклад 5.1. Уявімо БД "Навчальний процес" в вигляді реляційної моделі (табл. 5.1). Далі відносини (наприклад, табл. 5.1, а) будемо записувати і в іншій формі:

ГРУПА (Шифр групи. Назва, Кількість {студентів}, Средній_балл).

Підкреслений атрибут є ключовим.

Таблиця 5.1

а) Відношення "Група"

Шіфр_группи

Назва

Кількість

Середній бал

1

І | 1

16

4,3

2

И2

23

4,0

3

И3

18

4,2

б) Відношення "Студент"

Номер_еач_кі

Шіфр_группи

ПІБ студента

Рік народження

Середній бал

І-тисяча сімсот сорок шість

1

Сірої А.П.

Тисячу дев'ятсот сімдесят дев'ять

4,1

І-1 747

2

Кіров П.Г.

1980

4,0

І-тисяча сімсот сорок вісім

3

Сухов П.Н.

Тисячу дев'ятсот вісімдесят один

4,5

в) Відношення "Кафедра:

Код кафедри

Назва

Телефон

Зав. кафедрою

1

ІіУС

154-12-86

Сорокін П.В.

2

АПП

171-12-05

Борисов Б.В.

3

ТПП

212-10-81

Степанов И.В.

г) Відношення "Викладач"

Табел_номер

ПІБ викладача

Уч_степень

Уч_званіе

Код кафедри

381

Шаталов А.С

д.т. н.

Професор

1

101

Сидоров А.Т.

К. т, н

Доцент

2

402

Тараканов П.Т.

к. ф.-м. н

Доцент

3

д) Відношення "Предмет"

Код предмету

Назва

Всього годин

Практ / лаборатор

Семестрон

П1

Інформатика

350

130

2

П2

Кібернетика

300

120

3

П3

Математика

600

200

4

е) Відношення "Вивчення"

Шіфр_группи

Кол предмета

Та6ел_номер

Вид занять

Годинники

2

П2

402

Практичні

2

П2

381

Лекції

1

П3

381

Лекції

1

П3

401

Практичні

ж) Відношення "Успішність"

Шіфр_ групи

Номеру_ зач_кн

Код предмету

Табел_ номер

Вид занять

Оцінка

1

І-тисяча сімсот сорок шість

П3

381

Іспит

5

2

І-1 747

П3

381

Іспит

4

3

І-тисяча сімсот сорок вісім

П3

381

Іспит

3

Схема зв'язків БД

Рис. 5.1. Схема зв'язків БД "Навчальний процес"

Процедури створення і використання реляційних БД грунтуються на теорії реляційних БД, докладно розглянутої в гл. 4. Її результати використовуємо в прикладних цілях. При введенні структури даних використовують відповідні формати даних. Для таблиці "Викладач" вони представлені в табл. 5.2. Вся БД (табл. 5.1) представлена в 4НФ, тому відобразимо схему зв'язків між її відносинами (рис. 5.1), де підкреслені поля - первинні ключі. Уточнений (в процесі проектування) перелік таблиць і полів з їх форматами даних наведено у додатку 1, а схема зв'язків - в гол. 5.

Таблиця 5.2

Формати типів даних відносини "Викладач"

Ім'я поля

Ключ

Унікальне поле

Обов'язкове поле

Тип даних

Розмір

Підписи поля

Табел_номер

Первинний

Та

Та

Числовий

Ціле

Таб N

ПІБ викладача

-

Немає

Та

Текстовий

30

ПФІО

Уч_степень

-

Немає

Немає

Текстовий

12

Уч_ст

Уч_званіе

-

Немає

Немає

Текстовий

12

Уч_зп

Код кафедри

Зовнішній

Немає

Та

Текстовий

6

Код_каф

 
Якщо Ви помітили помилку в тексті позначте слово та натисніть Shift + Enter
< Попередня   ЗМІСТ   Наступна >
 
Дисципліни
Агропромисловість
Аудит та Бухоблік
Банківська справа
БЖД
Географія
Документознавство
Екологія
Економіка
Етика та Естетика
Журналістика
Інвестування
Інформатика
Історія
Культурологія
Література
Логіка
Логістика
Маркетинг
Медицина
Нерухомість
Менеджмент
Педагогіка
Політологія
Політекономія
Право
Природознавство
Психологія
Релігієзнавство
Риторика
Соціологія
Статистика
Техніка
Страхова справа
Товарознавство
Туризм
Філософія
Фінанси
Пошук