Основи проектування баз даних
Поняття бази даних і СУБД
Сприйняття реального cвіту можна співвіднести з послідовністю різних, хоча іноді і взаємозв’язаних, явищ. З давніх часів люди намагалися описати ці явища (навіть тоді, коли не могли їх зрозуміти). Такий опис називають даними.
База даних (БД) – це засіб накопичення і організації великих масивів інформації про об’єкти деякої предметної області (ПО). БД повинна відображати поточні дані про предметну область, накопичувати, зберігати інформацію і надавати різним категоріям користувачів швидкий доступ до даних. Для цього дані в базі мають бути структуровані відповідно до деякої моделі, що відображає основні об’єкти ПО, їх властивості і зв’язки між ними. БД є частиною складної системи, званої банком даних або системою баз даних (СБД).
Досвід використання баз даних дозволяє виділити загальний набір їх робочих характеристик:
¾ повнота – чим повніше база даних, тим ймовірніше, що вона містить потрібну інформацію (проте, не повинно бути надмірної інформації);
¾ правильна організація – чим краще структурована база даних, тим легко в ній знайти необхідні відомості;
¾ актуальність – будь-яка база даних може бути точною і повною, якщо вона постійно оновлюється, тобто необхідно, щоб база даних в кожен момент часу повністю відповідала стану об’єкту, що відображався нею;
¾ зручність для використання – база даних має бути проста і зручна у використанні і мати розвинені методи доступу до будь-якої частини інформації.
Нижче перераховані основні функції СУБД.
Визначення даних – визначити, яка саме інформація зберігатиметься в базі даних, задасть властивості даних, їх тип (наприклад, число цифр або символів), а також вказати, як ці дані зв’язані між собою. В деяких випадках є можливість задавати формати і критерії перевірки даних.
Обробка даних – дані можуть оброблятися самими різними способами. Можна вибирати будь-які поля, фільтрувати і сортувати дані. Можна об’єднувати дані з іншою, пов’язаною з ними, інформацією і обчислювати підсумкові значення.
Управління даними – можна вказати, кому дозволено знайомитися з даними, коректувати їх або додавати нову інформацію. Можна також визначати правила колективного доступу.
Вхідні до складу сучасних СУБД засоби спільно виконують наступні функції:
опис даних, їх структури (звичайний опис даних і їх структури відбувається при ініціації нової бази даних або додаванні до існуючої бази нових розділів (стосунків); опис даних необхідний для контролю коректності використання даних, для підтримки цілісності бази даних);
первинне введення, поповнення інформації в базі даних;
видалення застарілої інформації з бази даних;
коректування даних для підтримки їх актуальності;
впорядкування (сортування) даних по деяких ознаках;
пошук інформації по деяких ознаках (для опису запитів є спеціальна мова запитів, він забезпечує також інтерфейс між базою даних і прикладними програмами користувачів, дозволяє цим програмам використовувати бази даних);
підготовку і генерацію звітів (засоби підготовки звітів дозволяють створювати і роздруковувати зведення по заданих формах на основі інформації бази даних);
захист інформації і розмежування доступу користувачів до неї (деякі розділи бази даних можуть бути закриті для користувача зовсім, відкриті тільки для читання або відкриті для зміни; крім того, при многопользовательськом режимі роботи з базою даних необхідно, щоб зміни вносилися коректно; для збереження цілісності даних служить механізм трансакцій при маніпулюванні даними – виконання маніпуляцій невеликими пакетами, результати кожного з яких у разі виникнення некоректності операцій “відкатуються” і дані повертаються до початкового стану);
резервне збереження і відновлення бази даних, яке дозволяє відновити втрачену при збоях і аваріях апаратури інформацію бази даних, а також накопичити статистику роботи користувачів з базою даних;
підтримку інтерфейсу з користувачами, який забезпечується засобами ведення діалогу (у міру розвитку і вдосконалення СУБД цей інтерфейс стає все більш дружнім; дружність існуючих засобів інтерфейсу припускає наявність розвиненої системи допомоги (підказки), до якої у будь-який момент може звернутися користувач, не перериваючи сеансу роботи з комп’ютером і базою даних;
захист від необдуманих дій, застережливий користувача і запобігаючу втрату інформації у разі поспішних або помилкових команд;
наявність декількох варіантів виконання одних і тих же дій, з яких користувач може вибрати найбільш зручні для себе, відповідні його підготовці, кваліфікації, звичкам;
ретельно продуману систему ведення людино-машинного діалогу, відображення інформації на дисплеї, використання клавіш клавіатури).
Розрізняють три типи СУБД:
¾ ієрархічна;
¾ мережева;
¾ реляційна.
Ієрархічна модель даних
Найбільш відомим і поширеним представником такої моделі даних є СУБД IMS (Information Management System) компанії IBM. Перша версія системи з’явилася в 1968 р.
Ієрархічна БД складається з впорядкованого набору дерев; точніше, з впорядкованого набору декількох екземплярів одного типу дерева. Тип дерева складається з одного «кореневого» типу запису і впорядкованого набору з нуля або більш за типи піддерев (кожне з яких є деяким типом дерева). Тип дерева в цілому є ієрархічно організованим набором типів запису. Або іншими словами, дані представляються у вигляді дерева з одним кореневим вузлом і з умовами, що кожен вузол нижче кореневого може бути пов’язаний з одним вищестоящим вузлом і з декількома нижчестоячими вузлами.
У розглянутому прикладі тип запису Відділ є предком для типів запису Керівник і Службовці, а Керівник і Службовці – нащадки типу запису Відділ. Сенс полів типів записів в основному має бути зрозумілий по їх іменах. Поле Рук_отдел типу запису Керівник містить номер відділу, в якому працює службовець, що є даним керівником (передбачається, що він працює не обов’язково в тому ж відділі, яким керує). Між типами запису підтримуються зв’язки.
Один екземпляр дерева приведеного в прикладі мав би наступний вигляд:
Всі екземпляри даного типу нащадка із загальним екземпляром типу предка називаються близнюками. Для ієрархічної бази даних визначається повний порядок обходу дерева: зверху-вниз, зліва-направо.
У ієрархічній моделі даних автоматично підтримується цілісність посилань між предками і нащадками. Основне правило: ніякий нащадок не може існувати без свого батька.
Недоліки: якщо дані не мали деревовидної структури, то виникала маса складнощів при побудові ієрархічної моделі і бажанні добитися потрібної продуктивності.
Мережева модель даних
Типовим представником систем, заснованих на мережевій моделі даних, є СУБД IDMS (Integrated Database Management System), розроблена компанією Cullinet Software, Inc. і спочатку орієнтована на використання на мейнфреймах компанії IBM. Архітектура системи заснована на пропозиціях Data Base Task Group (DBTG) організації CODASYL (Conference on Data Systems Languages), яка відповідала за визначення мови програмування COBOL. Звіт DBTG був опублікований в 1971 р., і незабаром після цього з’явилося декілька систем, що підтримують архітектуру CODASYL, серед яких присутня і СУБД IDMS. В даний час IDMS належить компанії Computer Associates.
Мережевий підхід до організації даних є розширенням ієрархічного підходу. У ієрархічних структурах запис-нащадок повинен мати в точності одного предка; у мережевій структурі даних у нащадка може бути будь-яке число предків.
Мережева БД складається з набору записів і набору зв’язків між цими записами, а якщо говорити точніше, з набору екземплярів кожного типу із заданого в схемі БД набору типів запису і набору екземплярів кожного типу із заданого набору типів зв’язку.
Тип зв’язку визначається для двох типів запису: предка і нащадка. Екземпляр типу зв’язку складається з одного екземпляра типу запису предка і впорядкованого набору екземплярів типу запису нащадка. Для даного типу зв’язку L з типом запису предка P і типом запису нащадка C повинні виконуватися наступні дві умови:
¾ кожен екземпляр типу запису P є предком тільки в одному екземплярі типу зв’язку L;
¾ кожен екземпляр типу запису C є нащадком не більше ніж в одному екземплярі типу зв’язку L.
Розглянемо приклад схеми мережевої БД.
На рисунку показано три типи запису: Відділ, Службовці і Керівник і три типи зв’язку: Складається із службовців, Має керівника і Є таким, що служить.
У типі зв’язку Складається із службовців типом запіси-предком є Відділ, а типом запіси-потомком – Службовці (екземпляр цього типу зв’язку зв’язує екземпляр типу запису Відділ з багатьма екземплярами типу запису Службовці, відповідними всім службовцем даного відділу).
У типі зв’язку Має керівника типом запіси-предком є Відділ, а типом запіси-потомком – Керівник (екземпляр цього типу зв’язку зв’язує екземпляр типу запису Відділ з одним екземпляром типу запису Керівник, відповідним керівникові даного відділу).
Нарешті, в типі зв’язку Є служащим типом запіси-предком, є Керівник, а типом запіси-потомком – Службовці (екземпляр цього типу зв’язку зв’язує екземпляр типу запису Керівник з одним екземпляром типу запису Службовці, відповідним тому службовцеві, яким є даний керівник).
Недоліки: складність структури.
Реляційна модель даних
За минулі десятиліття реляційна модель розвивалася в двох напрямах. Перший напрям заклав знаменитий експериментальний проект компанії IBM System R. У цьому проекті виникла мова SQL, спочатку заснований на ідеях Кодда, але що порушує деякі принципові розпорядження реляційній моделі.
Другий напрям, починаючи з 1990-х рр., очолює Крістофер Дейт, до якого пізніше прилучився Хью Дарвен. Проте в 1990-і рр. Дейт і Дарвен прийшли до висновку, що спотворення реляційної моделі даних, властиві мові SQL, досягли настільки високого рівня, що прийшло час запропонувати альтернативу, що спирається на неспотворені ідеї Едгара Кодда і забезпечує всі можливості як SQL, так і об’єктно-орієнтованого підходу до організації баз даних і СУБД.
Назва “реляційна” (у перекладі з англійського relation – відношення) пов’язана з тим, що кожен запис в таблиці містить інформацію, що відноситься тільки до одного конкретного об’єкту.
Детальніше реляційну модель даних розглянемо пізніше.
Рівні моделі даних.
Проектування бази даних треба починати з аналізу наочної області і виявлення вимог до неї окремих користувачів. Проектування зазвичай доручається людині (групі осіб) – адміністраторові бази даних (АБД). Їм може бути як спеціально виділений співробітник організації, так і майбутній користувач бази даних, досить добре знайомий з машинною обробкою даних.
Виділяють три рівні моделі даних:
¾ інфологічна;
¾ даталогична;
¾ фізична.
Інфологічна модель описує предметну область на змістовному рівні. На першому етапі при її розробці здійснюється аналіз предметної області, вирішуваних завдань, запитів користувачів і документів, що відображають події і процеси, що протікають в ПО. Результатом цього аналізу є списки об’єктів предметної області, переліки їх властивостей або атрибутів, визначення зв’язків між об’єктами і опис структури ПО у вигляді діаграми. Для кожного з атрибутів указуються обмеження на їх можливі значення, визначувані властивостями ПО.
Такі обмеження називаються обмеженнями цілісності даних.
Інфологичеськая модель об’єднує в єдине узагальнене уявлення вимоги окремих користувачів і служить засобом спілкування між ними, тому розробляється без урахування особливостей представлення даних в пам’яті ЕОМ.
Концептуальна або даталогичеськая модель описує об’єкти і зв’язки ПО на формальному рівні. Її розробка ведеться на другому етапі і грунтується на інфологичеськой моделі, отриманій на першому етапі. В процесі розробки здійснюється вибір типу моделі даних, і визначаються її елементи. Кожна СУБД підтримує тільки одну з моделей. Вибір моделі даних і вибір СУБД тісно взаємозв’язані.
Внутрішня, або фізична, модель даних визначає спосіб розміщення даних безпосередньо на машинному носієві, враховує розподіл даних, методи доступу і способи індексування. У сучасних прикладних програмних засобах цей рівень організації забезпечується автоматично без втручання користувача. Користувач, як правило, оперує в прикладних програмах і універсальних програмних засобах представленнями СУБД на організацію даних.
Таким чином основне завдання проектування полягає в створенні інфологичеськой моделі ПО і концептуальною БД.
Інфологичеська модель даних “суть-зв’язок”
Основні поняття інфологичеського моделювання. Суть. Атрибут. Ключ. Зв’язок. Основні класи суті. ER-диаграммы і мова інфологичеського моделювання. Чотири види зв’язків.
Поняття, використовувані в інфологичному моделюванні.
Модель була запропонована Пітером Ченом (Peter Chen) в 1976 р. Моделювання наочної області базується на використанні графічних діаграм, що включають невелике число різнорідних компонентів.
Мета інфологичного моделювання – забезпечення найбільш природних для людини способів збору і представлення тієї інформації, яку передбачається зберігати в створюваній базі даних. Тому інфологичну модель даних намагаються будувати по аналогії з природною мовою. Основними конструктивними елементами інфологичеських моделей є суть, зв’язки між ними і їх властивості (атрибути).
Суть – будь-який помітний об’єкт (об’єкт, який ми можемо відрізнити від іншого), інформацію про яке необхідно зберігати в базі даних. Суттю можуть бути люди, місця, літаки, рейси, смак, колір і так далі Необхідно розрізняти такі поняття, як тип суті і екземпляр суті.
Поняття тип суті відноситься до набору однорідних осіб, предметів, подій або ідей, промовців як ціле. Екземпляр суті відноситься до конкретної речі в наборі. Наприклад, типом суті може бути МІСТО, а екземпляром – Москва, Київ і так далі
Атрибут – пойменована характеристика суті. Його найменування має бути унікальним для конкретного типу суті, але може бути однаковим для різного типу суті (наприклад, КОЛІР може бути визначений для багатьох суті: СОБАКА, АВТОМОБІЛЬ, ДІМ і так далі). Атрибути використовуються для визначення того, яка інформація має бути зібрана про суть. Прикладами атрибутів для суті АВТОМОБІЛЬ є ТИП, МАРКА, НОМЕРНИЙ ЗНАК, КОЛІР і так далі
Тут також існує відмінність між типом і екземпляром. Тип атрибуту КОЛІР має багато екземплярів або значень: Червоний, Синій, Банановий, Біла ніч і так далі, проте кожному екземпляру суті привласнюється тільки одне значення атрибуту.
Ключ – мінімальний набір атрибутів, по значеннях яких можна однозначно знайти необхідний екземпляр суті. Мінімальність означає, що виключення з набору будь-якого атрибуту не дозволяє ідентифікувати суть по тих, що залишилися. Для суті Розклад ключем є атрибут «Номер рейса» або набір: «Пункт відправлення», «Час вильоту» і «Пункт призначення» (за умови, що з пункту в пункт вилітає в кожен момент часу один літак).
Зв’язок – асоціювання два або більш за суть. Якби призначенням бази даних було тільки зберігання окремих, не зв’язаних між собою даних, то її структура могла б бути дуже простій. Проте одна з основних вимог до організації бази даних – це забезпечення можливості відшукання однієї суті по значеннях інших, для чого необхідно встановити між ними певні зв’язки. А оскільки в реальних базах даних нерідко містяться сотні або навіть тисячі суті, то теоретично між ними може бути встановлене більше мільйона зв’язків. Наявність такої безлічі зв’язків і визначає складність інфологичеських моделей.
Основні класи суті.
Існують три основні класи суті: стрижньові, асоціативні і характеристичні, а також підклас асоціативної суті – позначення.
Стрижньова суть (стрижень) – це незалежна суть. Наприклад стрижнями є: “Студент”, “Квартира”, “Чоловіки”, “Лікар”, “Брак”.
Асоціативна суть (асоціація) – це зв’язок виду “многие-ко-многим” між двома або більш суттю. Асоціації розглядаються як повноправна суть: вони можуть брати участь в інших асоціаціях і позначеннях точно так, як і стрижньова суть; можуть володіти властивостями, тобто мати не тільки набір ключових атрибутів, необхідних для вказівки зв’язків, але і будь-яке число інших атрибутів, що характеризують зв’язок. Наприклад, асоціація “Брак” містять ключові атрибути “Код_м”, “Код_ж” і “Табельний номер чоловіка”, “Табельний номер дружини”, а також уточнюючі атрибути “Номер свідоцтва”, “Дата реєстрації”, “Место_регистрациі”, “Номер запису в книгу ЗАГС” і так далі
Характеристична суть (характеристика) – це зв’язок виду “многие-к-одной” або “одна-к-одной” між двома суттю (окремий випадок асоціації). Єдина мета характеристики в рамках даної наочної області полягає в описі або уточненні деякій іншій суті.
Позначаюча суть або позначення – це зв’язок виду “многие-к-одной” або “одна-к-одной” між двома суттю і відрізняється від характеристики тим, що не залежить від суті, що позначається.
Позначення і характеристики не є повністю незалежною суттю, оскільки вони припускають наявність деякій іншій суті, яка “позначатиметься” або “характеризуватиметься”. Проте вони все ж таки є окремими випадками суті і можуть, звичайно, мати властивості, можуть брати участь в асоціаціях, позначеннях і мати свої власні (нижчого рівня) характеристики. Підкреслимо також, що всі екземпляри характеристики мають бути обов’язково пов’язані з яким-небудь екземпляром суті, що характеризується. Проте допускається, щоб деякі екземпляри суті, що характеризується, не мали зв’язків.
Перевизначимо тепер стрижньову суть як суть, яка не є ні асоціацією, ні позначенням, ні характеристикою. Така суть має незалежне існування.
На закінчення розглянемо приклад побудови інфологичеськой моделі бази даних “Живлення”, де повинна зберігатися інформація про блюда, їх щоденне споживання, продукти, з яких готуються ці блюда, і постачальників цих продуктів. Інформація використовуватиметься кухарем і керівником невеликого підприємства громадського харчування, а також його відвідувачами.
За допомогою вказаних користувачів виділені наступні об’єкти і характеристики проектованої бази:
¾ Блюда, для опису яких потрібні дані, що входять в їх кулінарні рецепти: номер блюда (наприклад, з книги кулінарних рецептів), назва блюда, вид блюда (закуска, суп, гарячіше і тому подібне), рецепт (технологія приготування блюда), вихід (вага порції), назва, калорійність і вага кожного продукту, що входить в блюдо.
¾ Для кожного постачальника продуктів: найменування, адреса, назва продукту, що поставляється, дата постачання і ціна на момент постачання.
¾ Щоденне споживання блюд (витрата): блюдо, кількість порцій, дата.
Аналіз об’єктів дозволяє виділити:
¾ Стрижні: Блюда, Продукти і Міста;
¾ Асоціації: Склад (пов’язує Блюда з Продуктами) і Постачання (пов’язує Постачальників з Продуктами);
¾ Позначення: Постачальники;
¾ Характеристики: Рецепти і Витрата.
ER- діаграми і мова інфологичеського моделювання (ЯІМ)
При побудові інфологичеських моделей можна використовувати мову ER-диаграмм.
У них суть зображається поміченими прямокутниками, асоціації – поміченими ромбами або шестикутниками, атрибути – поміченими овалами, а зв’язки між ними – ненапрямленими ребрами, над якими може проставлятися ступінь зв’язку (1 або буква, замінююча слово “багато”) і необхідне пояснення.
Мова ER-диаграмм використовується для побудови невеликих моделей і ілюстрації окремих фрагментів великих. Частіше ж застосовується менш наочна, але змістовніша мова інфологичеського моделювання (ЯІМ), в якому суть і асоціації представляються пропозиціями вигляду:
СУТЬ (атрибут 1, атрибут 2 , ..., атрибут n)
АСОЦІАЦІЯ [СУТЬ S1, СУТЬ S2 ...]
(атрибут 1, атрибут 2, ..., атрибут n)
ХАРАКТЕРИСТИКА (атрибут 1, атрибут 2, …)
{ СПИСОК, ЩО ХАРАКТЕРИЗУЄТ СУТЬ}
ПОЗНАЧЕННЯ (атрибут 1, атрибут 2, …)
[СПИСОК, ЩО ХАРАКТЕРИЗУЄТ СУТЬ]
де S – ступінь зв’язку, а атрибути, що входять в ключ, мають бути відмічені за допомогою підкреслення.
Для прикладу бази даних “Живлення” модель на мові ЯЇМ має наступний вигляд:
Блюда (БЛ, Блюдо, Вигляд)
Продукти (ПР, Продукт, Калорійність)
Постачальники (ПОС, Місто, Постачальник) [Місто]
Склад [Блюда M, Продукти N] (БЛ, ПР, Вага (г))
Постачання [Постачальники M, Продукти N] (ПОС, ПР, Дата_п, Ціна, Вага (кг))
Міста (Місто, Країна)
Рецепти (БЛ, Рецепт) { Блюда}
Витрата (БЛ, Дата_р, Порцій) { Блюда}
Реляційна база даних
Основні поняття. Правила побудови реляційних баз даних. Нормалізація. Процес проектування.
Основні поняття, використовувані в реляційних базах даних
У 1970 р. Е.Ф. Кодд (E.f. Codd) опублікував свою статтю, в якій він застосував концепції розділу математики, званого реляційною алгеброю, до проблеми зберігання великих об’ємів даних. Стаття Кодда поклала початок руху у сфері проектування баз даних, яке привело декілька років опісля до створення реляційної моделі бази даних. Ця модель є певним способом структуризації і обробки бази даних.
Перевага реляційної моделі полягає в способі зберігання даних, який мінімізує їх дублювання і виключає певні типи помилок обробки, що виникають при інших способах зберігання даних. Дані зберігаються у вигляді таблиць.
Згідно реляційної моделі, не всі види таблиць однаково прийнятні. За допомогою процесу, званого нормалізацією, небажана таблиця може бути перетворена в дві або прийнятніших.
Введемо наступні позначення:
¾ Суть – Таблиця (іноді Файл),
¾ Екземпляр суті – Рядок (іноді Запис),
¾ Атрибут – Стовпець, Поле.
При цьому приймається, що “запис” означає “екземпляр запису”, а “поле” означає “ім’я і тип поля”.
Ключ або можливий ключ – це мінімальний набір атрибутів, по значеннях яких можна однозначно знайти необхідний екземпляр суті. Мінімальність означає, що виключення з набору будь-якого атрибуту не дозволяє ідентифікувати суть по тих, що залишилися. Кожна суть володіє хоч би одним можливим ключем. Одін з них береться за первинний ключ. При виборі первинного ключа слід віддавати перевагу нескладеним ключам або ключам, складеним з мінімального числа атрибутів. Недоцільно також використовувати ключі з довгими текстовими значеннями (переважно використовувати цілочисельні атрибути). Первинний ключ має бути унікальним.
Реляційна база даних – це сукупність стосунків, що містять всю інформацію, яка повинна зберігатися в БД. Проте користувачі можуть сприймати таку базу даних як сукупність таблиць.
Правила побудови реляційних баз даних
Розглянемо основні правила побудови реляційних баз даних:
1. Кожна таблиця складається з однотипних рядків і має унікальне ім’я.
2. Рядки мають фіксоване число полів (стовпців) і значень (множинні поля і групи, що повторюються, недопустимі). Інакше кажучи, в кожній позиції таблиці на перетині рядка і стовпця завжди є в точності одне значення або нічого.
3. Рядки таблиці обов’язково відрізняються один від одного хоч би єдиним значенням, що дозволяє однозначно ідентифікувати будь-який рядок такої таблиці.
4. Стовпцям таблиці однозначно привласнюються імена, і в кожному з них розміщуються однорідні значення даних (дати, прізвища, цілі числа або грошові суми).
5. Повний інформаційний зміст бази даних представляється у вигляді явних значень даних і такий метод уявлення є єдиним. Зокрема, не існує яких-небудь спеціальних “зв’язків” або покажчиків, що сполучають одну таблицю з іншою. Так, зв’язки між рядком з БЛ = 2 таблиці “Блюда” на рис. 3.1 і рядком з ПР = 7 таблиць продукти (для приготування Харчо потрібний Ріс), представляється не за допомогою покажчиків, а завдяки існуванню в таблиці “Склад” рядка, в якому номер блюда дорівнює 2, а номер продукту – 7.
6. При виконанні операцій з таблицею її рядка і стовпці можна обробляти у будь-якому порядку безвідносно до їх інформаційного змісту. Цьому сприяє наявність імен таблиць і їх стовпців, а також можливість виділення будь-якого їх рядка або будь-якого набору рядків з вказаними ознаками (наприклад, рейсів з пунктом призначення “Париж” і часом прибуття до 12 годин).
