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

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

З моменту появи поняття "база даних" виникла необхідність у теоретичній математичної підтримки процесів у ній. Поступово виявилися три відносно самостійні частини теорії баз даних: 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].

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