Загальна теорія баз даних

З моменту появи поняття "база даних" виникла необхідність у теоретичній математичної підтримки процесів у ній. Поступово виявилися три відносно самостійні частини теорії баз даних: 1) побудова баз даних; 2) використання баз даних; 3) функціонування баз даних. Вони вишикувалися у відносно струнку систему пізніше в рамках реляційних БД.

В даний час при проектуванні структур даних застосовують трьох основних підходи.

  • 1. Збір інформації в рамках однієї таблиці і подальша її декомпозиція.
  • 2. Використання CASE-технології [2].
  • 3. Структурування інформації в процесі проведення системного аналізу на основі сукупності правил і рекомендацій.

Спочатку на роль теорії баз даних незалежно від використовуваної моделі даних претендувала CASE-технологія. Пізніше з'ясувалося, що CASE-технологія охоплює лише процедуру побудови БД, та й то не повністю.

Широке поширення реляційних БД призвело до необхідності додавання в CASE-технологію процедури нормалізації, що є частиною теорії реляційних баз даних, на основі ER-диаг- рамм. Процедура нормалізації була формалізована і реалізована на комп'ютері (в діалоговому варіанті) в ряді СУБД (Access, Oracle). Разом з тим, побудова ER-діаграм - процедура специфічна.

Виникають складнощі і з процедурою нормалізації [2,3].

У зв'язку з цим реляційні БД частіше проектують, застосовуючи поняття "ставлення".

У той же час в CASE-технології закладені можливості автоматизації процедури проектування баз даних, що особливо важливо при створенні баз даних великої розмірності (20 Гбайт і вище).

Моделі представлення даних

БД, як елемент системи прийняття рішень (наприклад, в АСУ) є відображення предметної області реального світу [9]: її об'єкти, відносини між ними і відносини в БД повинні відповідати один одному. Комп'ютер (і АСУ зокрема) оперує тільки формальними поняттями (моделями), відповідними об'єктам і зв'язкам зовнішнього світу. В даний час є понад тридцять моделей подання даних, які до останнього часу не були систематизовані.

Їх можна розділити на дві групи:

  • 1) формальні (математичні, швидше теоретичні), які передбачають розробку БД обов'язково за участю людини;
  • 2) математичні уявлення, розраховані на автоматизацію процесу проектування БД ("комп'ютерне вистава").

Друга група розглянута в парагр. 3.2, а першу обговоримо тут.

Відразу відзначимо різницю двох понять [9 |: "модель даних" - засіб моделювання; "модель БД" - результат розробки БД. Модель (подання) БД - безліч конкретних обмежень над об'єктами і операціями з ними.

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

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

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

Найпростіше структуру (відношення) можна задати таблицею з "плоскою" (див. Табл. 1.11) або складної (див. Табл. 1.12) структурою. При такому завданні добре видно елементи (стовпці, поля), проте погано проглядаються відносини, які можуть бути чотирьох типів: 1: 1, 1: М, M: l, M: N.

Більш наочним (особливо для представлення типу 1: 1) є подання у вигляді орієнтованого графа (рис. 3.1), що сходить до математики, теорії автоматичного управління і теорії інформації. Елементами п (п належить N) графа Г (N, U) є стовпці (поля), а зв'язки між ними визначаються дугами і належить U). Такому графу відповідає матриця суміжності (табл. 3.1) або дводольний граф. Різновидом графів є запропоновані Д. Мартін овал-діаграми (рис. 3.2).

Орієнтований граф

Рис. 3.1. Орієнтований граф:

1-5 - вузли графа

Овал-діаграма

Рис. 3.2. Овал-діаграма: 1-5 - вузли діаграми

Таблиця 3.1

Матриця суміжності

1

2

3

4

5

1

0

0

1

1

1

2

0

0

0

0

1

3

0

0

0

0

0

4

0

0

0

0

0

5

0

0

0

0

0

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

  • • зв'язку в моделях представлення даних відносно прості (див. Рис. 3.1), матриці суміжності виходять розрідженими, що знижує цінність їх використання;
  • • у графах відбивається найчастіше один тип зв'язку (наприклад, 1: 1): виходом тут може бути використання овал-діаграм;
  • • при постановці завдання представлення (моделювання) даних, на відміну від теорії управління і математики, в яких широко використовуються початкові припущення, великий обсяг неформальної складової.

Для подолання третього утруднення сформувалися моделі представлення даних "сутність - зв'язок" (Entity - Relationship), звані також "ER-моделями (діаграмами)" або "моделями Чена". Базовими структурами в ER-моделі є "типи сутностей" і "типи зв'язків".

Відмінність типу зв'язку від типу сутності - у встановленні залежності існування реалізації одного типу від існування реалізації іншого. (Наприклад, ОСОБИСТІСТЬ - тип сутності, тип Одружений - немає, оскільки реалізація останнього типу не існує, якщо не існує двох особистостей. Тип зв'язку може розглядатися тому як агрегат двох або більше типів сутностей.)

Виділяють три типи зв'язку: зв'язок "один до одному" (1: 1), зв'язок "один до багатьох" (1: М), зв'язок "багато до багатьох" (M: N).

Приклади цих зв'язків можуть бути наступні:

Слід відзначити особливості відображення ER-моделі. Виділяють такі типи зв'язків:

  • • рекурсивне (по "кільцю") безліч зв'язків, в якому беруть участь кілька сутностей;
  • • дві множини зв'язків між одними і тими ж двома множинами сутностей;
  • • безліч n -арні зв'язків, наприклад тернарних (чотири зв'язку, "виходять від однієї сутності").

Виділення цих зв'язків є вкрай важливим, оскільки зв'язку 1: М і M: N мають внутрішню невизначеність, що позначається при операціях модифікації. Для подолання невизначеності на етапі реалізації логічної моделі потрібно вводити надлишкову інформацію.

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

Частковий концептуальної моделі предметної області "Навчальний процес" представлений на рис. 3.3, а приклад уявлення атрибутів для конкретного об'єкта показаний на рис. 3.4. Виділяють багатозначний атрибут, атрибут безлічі зв'язків.

У загальному випадку атрибути відображаються або на самій ER-диаг- рамме (при невеликій кількості об'єктів), або у вигляді окремих додатків по кожному об'єкту.

ER-діаграма предметної області

Рис. 3.3. ER-діаграма предметної області "Навчальний процес"

При побудові ER-моделей у ряді випадків доцільно виділяти ряд обмежень:

  • • обмеження цілісності стосовно до атрибутам: (наприклад: N - студенти, ціле, позитивне, число студентів - діапазон від 5 до 35);
  • • обмеження Е по існуванню сутностей (рис. 3.3);
  • • ID-залежність (рис. 3.3): сутність не може бути ідентифікована в ряді випадків за значеннями власних атрибутів.

Тут прямокутниками показані типи сутностей і атрибути, ромбами - типи зв'язків.

Покажемо властивості цих моделей на прикладі БД "Навчальний процес" в інституті (рис. 3.4). Укрупнено (і в дещо іншому накресленні, ніж на рис. 3.3) він може бути представлений у вигляді відносин трьох груп атрибутів (рис. 3.4, а) зі зв'язками Μ: Ν і 1: М. Оскільки групи 1 і 3 - множини, схему можна представити у вигляді рис. 3.4, б. Відомо, що жодна модель даних не може реалізувати відносини Μ: Ν. У зв'язку з цим схема зв'язків після перетворення остаточно виглядає, як показано на рис. 3.4, в.

Модель БД

Рис. 3.4. Модель БД "Навчальний процес": а - вихідна структура; б - проміжна структура; в - результат

Зауважимо, що перераховані методи володіють наступними недоліками:

  • • слабо орієнтовані на використання комп'ютерів у проектуванні БД;
  • • оперують зі статичними (незмінними) даними, тоді як в реальних системах управління використовуються динамічні дані (потоки даних);
  • • відображають потоки даних не системно.

Названі недоліки усунуті в CASE-технології [25].

 
< Попер   ЗМІСТ   Наст >