1.4 Логічна модель та опис

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

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

У цій главі викладаються основні поняття і принципи організації реляційних БД, а також описуються базові підходи до проектування реляційних БД. Використовується поняття реляційної моделі даних, розглядаються структурні складові моделі, досить коротко описуються процеси нормалізації відносин і проектування реляційних БД на логічному і фізичному рівнях. Крім того, в цьому розділі наводяться особливості організації роботи з БД в архітектурі «клієнт-сервер».

Реляційна модель даних вперше була запропонована американським математиком Коддом в 1970 році [1]. Фундаментальним поняттям реляційної БД є ставлення. Це відображено і в загальній назві підходу - термін реляційний (реляційні) походить від співвідношення (відношення). На фізичному рівні відносини являють собою таблиці. У реляційній моделі всі дані представлені у вигляді простих таблиць, розбитих на рядки і стовпці. На жаль, практичне визначення поняття «реляційна база даних» виявилося набагато більш розпливчастим, ніж точне математичне визначення, дане цьому терміну Кодом в 1970 році. Постачальники СУБД реалізовували у своїх продуктах лише деякі риси реляційних систем, і, фактично, потенційні можливості і сенс реляційного підходу спотворювалися.

У відповідь на це в 1985 році Код написав статтю, де сформулював 12 правил, яким повинна задовольняти будь-яка база даних, що претендує на звання реляційної. Наведені нижче дванадцять правил Кодда вважаються визначенням реляційної СУБД [1, 2].

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

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

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

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

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

• визначення даних;

• визначення уявлень;

• обробку даних (інтерактивну і програмну);

• умови цілісності;

• ідентифікація прав доступу;

• кордону транзакцій (початок, завершення і скасування).

6. Правило поновлення уявлень. Всі вистави, які теоретично можна оновити, повинні бути доступні для оновлення.

7. Правило додавання, оновлення та видалення. Можливість працювати з відношенням (таблицею) як з одним операндом повинна існувати не тільки при читанні даних, але і при додаванні, оновленні і видаленні даних.

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

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

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

11. Правило незалежності розповсюдження. Реляційна СУБД не повинна залежати від потреб конкретного користувача.

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

Правило 1 нагадує неформальне визначення реляційної бази даних, наведене раніше.

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

Правило 3 вимагає, щоб відсутні дані можна було представити за допомогою недійсних значень (NULL).

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

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

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

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

Правила 8 і 9 означають відділення користувача та прикладної програми від низькорівневою реалізації бази даних. Вони стверджують, що конкретні способи реалізації зберігання або доступу, використовувані в СУБД, і навіть зміни структури таблиць бази даних не повинні впливати на можливість користувача працювати з даними.

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

Правило 11 свідчить, що мова бази даних повинен забезпечувати можливість роботи з розподіленими даними, розташованими на інших комп'ютерних системах.

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

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

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

У цьому посібнику використовується навчальна реляційна база даних, яка являє собою дуже спрощений приклад інформаційної моделі системи «Абонент +», використовуваної для інформаційного забезпечення діяльності газорозподільних організацій та регіональних компаній з реалізації газу [3]. Повний опис таблиць навчальної бази даних і що містяться в ній даних наведено в додатку А. Далі будуть розглянуті основні поняття реляційних баз даних на прикладі навчальної бази даних.

1.2. Таблиці

У реляційній базі даних інформація організована у вигляді реляційних таблиць, розділених на рядки і стовпці, на перетині яких містяться значення даних [4].

Таблиця - це деяка регулярна структура, що складається з кінцевого набору однотипних записів.

Таблиця відображає тип об'єкта реального світу (сутність). Рядки відповідають екземпляру об'єкта, конкретної події або явища. Стовпці відповідають атрибутам (ознаками, характеристиками, параметрами) об'єкта, події, явища. У кожної таблиці є унікальне ім'я усередині бази даних, що описує її зміст.

У кожного стовпця в таблиці є своє ім'я, яке зазвичай служить заголовком стовпця. Всі стовпці в одній таблиці повинні мати унікальні імена, однак дозволяється присвоювати однакові імена стовпців, розташованим в різних таблицях. У реляційній моделі даних атрибути відносин не впорядковані, тобто звернення до полів завжди відбувається по іменах, а не за розташуванням. Проте в мові SQL допускається індексне вказівку стовпців таблиць, при цьому стовпці розглядаються в порядку зліва направо (їх порядок визначається при створенні таблиці) [1].

У будь-якій таблиці завжди є як мінімум один стовпець. У стандарті ANSI / ISO не вказується максимально припустиме число стовпців в таблиці, проте майже у всіх комерційних СУБД ця межа існує. У СУБД Firebird ця межа становить32767стовпців.

У реляційній моделі даних для позначення рядка відносини використовується поняття кортеж. Виставою кортежу на фізичному рівні є рядок таблиці бази даних. Рядки таблиці не мають імен та певного порядку. У таблиці може міститися будь-яку кількість рядків. Цілком припустимо існування таблиці з нульовим кількістю рядків. Така таблиця називається порожньою. Порожня таблиця зберігає структуру, певну її стовпцями, просто в ній не містяться дані. Як правило, не накладається обмежень на кількість рядків у таблиці, і в багатьох

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

Проілюструємо більш наочно структуру однієї з таблиць навчальної бази даних (див. додаток А). На рис. 1.1 наведена структура таблиці Абонент, що містить відомості про абонентів газорозподільної організації.

Рисунок

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