MS ACCESS як система управління реляційними базами даних

До баз даних звертаються в тих випадках, коли виникає по­треба у збереженні й обробленні великих об’ємів інформації. Ви­користання текстового редактора для цих цілей неефективне з багатьох причин, зокрема із-за незручності пошуку і фільтрації даних. Як, наприклад, у редакторі MS Word одержати відразу всі входження слова «Access» у тексті документа? Електронні таблиці більше підходять для розробки інформаційних застосу­вань, проте обмеження на розмір аркуша, відсутність механізмів зв’язування і підтримки цілісності даних примушують відмови­тися від електронних таблиць при роботі з великими базами да­них складної структури. Крім вказаних причин файли тексто­вого редактора й електронних таблиць не дають змоги одночасно кільком користувачам змінювати дані навіть у разі, якщо вони працюють з різними сторінками документа.

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

Реляційна модель даних припускає, що дані представлені тільки в один спосіб, а саме у вигляді таблиць. Кожний рядок (Строчка) у таблиці містить інформацію, що стосується деякого конкретного об’єкта. Ця інформація є набором фактів, при цьому в колонці (стовпчику; а також атрибуті або полі) міститься кон­кретний факт. Колонки мають заголовки (імена), які і слугують для здобування потрібних фактів. Оскільки порядок колонок вва­жається невизначеним, то їх імена є єдиним засобом доступу до відповідного факту. Наприклад, таблиця «Співробітники» може мати колонки з іменами «П1Б співробітника» і «Телефон», що припускає наявність у цих колонках інформації про прізвище і телефон співробітника відповідно. Звичайно, СУБД не в змозі від- стежувати порушення сенсу інформації, про це повинен піклува­тися розробник додатку. Єдине, що може перевірити система при введенні інформації, — це тип даних, що вводяться, оскільки для кожної колонки тип даних визначається при створенні таблиці. При спробі ввести інформацію, тип якої не сумісний з типом да­них колонки, буде отримано повідомлення про помилку перетво­рення типу. Слід відмітити, що поняття домену (як допустимої безлічі значень) у реляційній теорії частково вирішує цю пробле­му. Але оскільки домени підтримуються далеко не всіма СУБД (і Access не виняток), ми не зупинятимемося на цьому.

Значення стовпчиків будуть атомарними, тобто їх можна ви­значити тільки на простих типах даних; іншими словами, зна­ченням стовпчика не може бути таблиця. Рядки таблиці (їх на­зивають також записами, або кортежами) неупорядковані, що означає, що для доступу до певного запису використовується не його порядковий номер, а лише значення в певному стовпчику або поєднання значень у декількох стовпчиках. У зв’язку з цим особливої важливості набуває потенційний ключ — стовпчик або набір стовпчиків (складений ключ), значення в якому (або набір значень) унікальне для всієї таблиці. Наявність ключа для табли­ці означає принципову можливість відрізнити один об’єкт бази даних від іншого. Це не завжди вдається реалізувати природним шляхом, наприклад, для групи однакових товарів, що не мають, скажімо, заводських номерів. У такому разі може використову­ватися так званий синтетичний ключ, тобто стовпчик, значення в якому не несуть ніякої інформації, а просто містять унікальні значення. Для цих цілей в Access навіть є спеціальний тип даних Счетчик, який автоматично генерує унікальні значення при до­даванні нового запису в таблицю.

Отже, реляційна теорія розглядає базу даних як набір таблиць. Візьмемо як приклад дві таблиці — «Співробітники» і «Пацієн­ти» . Інформація в цих таблицях логічно зв’язана, оскільки кожен пацієнт обслуговується або спостерігається якимось співробітни­ком. Такий зв’язок забезпечується наявністю в таблиці «Пацієн­ти» стовпчика, що ідентифікує співробітника, який спостерігає цього пацієнта в таблиці «Співробітники». Такий стовпчик (на­приклад, Код співробітника) має містити значення, що збігають­ся зі значеннями відповідного стовпчика (скажімо, ТабНомер) у таблиці «Співробітники». Для зв’язування значення в стовпчику ТабНомер мають бути унікальними, а саме цей стовпчик має бути потенційним ключем, інакше ми не зможемо сказати, який спів­робітник спостерігає даного пацієнта. Природно, унікальність не потрібна для стовпчика Код співробітника, оскільки один спів­робітник може спостерігати будь-яку кількість пацієнтів. Таким чином, реляційна модель реалізує зв’язок не за допомогою яких- небудь покажчиків, а тільки на підставі значень, що збігають ся, у стовпчиках різних таблиць.

У будь-якій реляційній таблиці може опинитися не один по­тенційний ключ, а декілька. Серед цих потенційних ключів мож­на вибрати один (і лише один) первинний ключ. Первинний ключ, на відміну від потенційних, повинен мати значення в кожному рядку таблиці, тобто інформація має бути відомою. Потенційний ключ не має цього обмеження, унаслідок чого поле потенційного ключа може містити спеціальні МТЛХ-значення, що означають відсутність інформації.

Наявність первинного ключа забезпечує так зване правило ка­тегоріальної цілісності, або цілісності об’єктів, яке свідчить, що кожен об’єкт у базі даних має бути однозначно ідентифікованим. Як наслідок, збереження запису в базі даних неможливе доти, доки не буде заповнено значення первинного ключа.

Повернімося до зв’язку між таблицями. Стан бази даних, при якому в таблиці «Пацієнти» у стовпчику Код співробітника наявне значення, відсутнє у стовпчику ТабНомер таблиці «Спів­робітники», називається неузгодженим. Для такого пацієнта співробітник невідомий. Ця ситуація, яка може виникнути при видаленні рядка з таблиці «Співробітники» або за рахунок при­пущення помилки при введенні інформації про пацієнта, назива­ється втратою посилальної цілісності. Зрозуміло, що наявність таких «вільних» пацієнтів породила б масу проблем при роботі з базою даних.

На щастя, СУБД автоматично забезпечує посилальну ціліс­ність за допомогою зовнішніх ключів. Зовнішнім ключем назива­ють такий набір стовпчиків однієї таблиці, який слугує потенцій­ним ключем для іншої (або тієї самої) таблиці. Зовнішній ключ за­безпечує узгоджений стан двох таблиць. У нашому прикладі таким зовнішнім ключем може бути стовпчик Код співробітника в таб­лиці «Пацієнти». Так от, якщо призначити стовпчик Код співро­бітника зовнішнім ключем до таблиці «Співробітники», тоді сис­тема буде стежити за узгодженістю даних, зокрема не можна буде ввести в цей стовпчик значення, що не відповідає жодному зі спів­робітників (відсутнє у стовпчику ТабНомер). Також не можна буде видалити співробітника (запис із таблиці «Співробітники»), якщо у цього співробітника є пацієнти (зв’язані записи в таблиці «Паці­єнти»). Таким чином, дії, що порушують посилальну цілісність, не виконуються; замість цього генеруватиметься повідомлення про помилку.

Відзначимо, що зовнішній ключ може посилатися на потен­ційний ключ у своїй власній таблиці; у цьому разі він називається рекурсивним зовнішнім ключем. Типовим прикладом такого зв’язку є ієрархічний зв’язок типу «начальник — підлеглий».

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

Перевірне обмеження встановлюють для стовпчика — це об­меження на введення допустимих значень у даний стовпчик. Це може бути простим перерахуванням значень або діапазоном (на­приклад, between 1 and 100 — число між 1 і 100). Проте тут допус­каються і складніші вирази, які можуть мати посилання на інші таблиці бази даних. Ці обмеження перевіряються при будь-якій зміні значення у відповідному стовпчику. Якщо перевірне обме­ження порушується, зміна анулюється, і видається відповідне по­відомлення про помилку.

Принципово неможливо забезпечити цілісність даних, ви­користовуючи зберігання кожної таблиці в окремому файлі. Це пов’язано з тим, що інформація про структури зберігання і обме­ження цілісності даних (метадані) має використовуватися систе­мою, яка реалізовує доступ. Якщо ж доступ можна організувати в обхід метаданих, то можна і привести базу даних в неузгоджений стан. MS Access зберігає всі дані і метадані в одному файлі (.mdb), що гарантує перевірку всіх обмежень при доступі до них за допо­могою будь-яких додатків, що підключаються до даного файла бази даних.

Реляційну модель було вперше запропоновано в 1970 році К.Ф. Коддом, який також увів дві мови маніпуляції даними — ре­ляційну алгебру і реляційне числення (авторам невідомий повний переклад російською мовою робіт Кодда, проте вичерпне викла­дення реляційної теорії можна також знайти у фундаментальній книзі Д. Дж. Дейта). Жодна з цих мов не використовується без­посередньо в реалізаціях СУБД. Проте вони послужили базою для створення мови SQL, яка є на сьогодні єдиною стандартизова­ною мовою взаємодії з реляційними базами даних і підтримуєть­ся всіма провідними виробниками на ринку реляційних СУБД. MS Access не буде тут винятком. Підтримуваний цим продуктом діалект мови SQL відповідає вимогам стандарту SQL-92 (ANSI і ISO).

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