Файл: Опорник.doc

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

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

Приклади реляційних СУБД: MySql, PostgreSql.

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

Приклади об'єктних СУБД: Cache, GemStone (від Servio Corporation), ONTOS (ONTOS).

Останнім часом виробники СУБД прагнуть з'єднати два ці підходи і проповідують об'єктно-реляційну модель представлення даних. Приклади таких СУБД – IBM DB2 for Common Servers, Oracle8.

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

2 Ключі

Спершу давайте подумаємо над таким питанням: яку інформацію потрібно дати про людину, щоб співбесідник точно сказав, що це саме та людина, сумнівів бути не може, іншого такого нема? Повідомити прізвище, очевидно, недостатньо, оскільки існують однофамільці. Якщо співбесідник людина, то ми можемо приблизно пояснити, про кого мова, наприклад пригадати вчинок, який здійснила та людина, або ще якось. Комп'ютер же такого пояснення не зрозуміє, йому потрібні чіткі правила, як визначити, про кого йде мова. В системах управління базами даних для вирішення такої задачі ввели поняття первинного ключа.

Первинний ключ (primary key, PK) – мінімальний набір полів, унікально ідентифікуючий запис в таблиці. Значить, первинний ключ – це в першу чергу набір полів таблиці, по-друге, кожний набір значень цих полів повинен визначати єдиний запис (рядок) в таблиці і, по-третє, цей набір полів повинен бути мінімальним зі всіх володіючих такою ж властивістю. Оскільки первинний ключ визначає тільки один унікальний запис, то ніякі два записи таблиці не можуть мати однакових значень первинного ключа .

Наприклад, в нашій таблиці (див. вище) ПІБ і адресу дозволяють однозначно виділити запис про людину. Якщо ж говорити загалом, без зв'язку з вирішуваною задачею, то такі знання не дозволяють точно вказати на єдину людину, оскільки існують однофамільці, що живуть в різних містах за однією адресою. Вся справа в межах, які ми самі собі задаємо. Якщо вважаємо, що знання ПІБ, телефону і адреси без вказівки міста для наших цілей достатньо, то все чудово, тоді поля ПІБ і адреса можуть утворювати первинний ключ. У будь-якому випадку проблема створення первинного ключа лягає на плечі того, хто проектує базу даних (розробляє структуру зберігання даних). Рішенням цієї проблеми може стати або виділення характеристик, які природним чином визначають запис в таблиці (завдання так званого логічного, або природного, PK), або створення додаткового поля, призначеного саме для однозначної ідентифікації записів в таблиці (завдання так званого сурогатного, або штучного, PK). Прикладом логічного первинного ключа є номер паспорта в базі даних об паспортних даних жителів або ПІБ і адресу в телефонній книзі (таблиця вище). Для завдання сурогатного первинного ключа в нашу таблицю можна додати поле id (ідентифікатор), значенням якого буде ціле число, унікальне для кожного рядка таблиці. Використовування таких сурогатних ключів має сенс, якщо природний первинний ключ є великим набором полів або його виділення нетривіальне.

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

Наприклад, у нас є три таблиці: що містить інформацію про історичних осіб (Persons), що містить інформацію про їх винаходи (Artifacts) і що містить зображення як осіб, так і артефактів (Images) (рис 10.1).

Первинним ключем у всіх цих таблицях є поле id (ідентифікатор). В таблиці Artifacts є поле author, в якому записаний ідентифікатор, привласнений автору винаходу в таблиці Persons. Кожне значення цього поля є зовнішнім ключем для первинного ключа таблиці Persons. Крім того, в таблицях Persons і Artifacts є поле photo, яке посилається на зображення в таблиці Images. Ці поля також є зовнішніми ключами для первинного ключа таблиці Images і встановлюють однозначний логічний зв'язок Persons-Images і Artifacts-Images. Тобто якщо значення зовнішнього ключа photo в таблиці особи рівне 10, то це значить, що фотографія цієї особи має id=10 в таблиці зображень. Таким чином, зовнішні ключі використовуються для організації зв'язків між таблицями бази даних (батьківськими і дочірніми) і для підтримки обмежень посилальної цілісності даних.

Мал. 10.1. Приклад використовування первинних ключів для організації зв'язків з іншими таблицями

3 Індексація

Одна з основних задач, що виникають при роботі з базами даних, – це задача пошуку. При цьому, оскільки інформації в базі даних, як правило, міститься багато, перед програмістами встає задача не просто пошуку, а ефективного пошуку, тобто пошуку за порівняно невеликий час і з достатньою точністю. Для цього (для оптимізації продуктивності запитів) проводять індексацію деяких полів таблиці. Використовувати індекси корисно для швидкого пошуку рядків з вказаним значенням одного стовпця. Без індексу читання таблиці здійснюється по всій таблиці, починаючи з першого запису, поки не будуть знайдені відповідні рядки. Чим більше таблиця, тим більше невигідні витрати. Якщо ж таблиця містить індекс по даних стовпцях, то база даних може швидко визначити позицію для пошуку в середині файлу даних без проглядання всіх даних. Це відбувається тому, що база даних поміщає проіндексовані поля ближче в пам'яті, так, щоб можна було пошвидше знайти їх значення. Для таблиці, що містить 1000 рядків, це буде як мінімум в 100 разів швидше в порівнянні з послідовним перебором всіх записів. Проте у разі, коли необхідний доступ майже до всіх 1000 рядків, буде швидше послідовне читання, оскільки при цьому не вимагається операцій пошуку по диску. Отже іноді індекси бувають тільки перешкодою. Наприклад, якщо копіюється великий об'єм даних в таблицю, то краще не мати ніяких індексів. Проте в деяких випадках вимагається задіювати відразу декілька індексів (наприклад, для обробки запитів до таблиць, що часто використовуються).

Якщо говорити про MySQL, то там існує три види індексів: PRIMARY, UNIQUE, і INDEX, а слово ключ (KEY) використовується як синонім слова індекс (INDEX). Всі індекси зберігаються в пам'яті у вигляді B-деревьев.

PRIMARY – унікальний індекс (ключ) з обмеженням, що всі індексовані їм поля не можуть мати порожнього значення (тобто вони мають позначку NOT NULL). Таблиця може мати тільки один первинний індекс, але він може складатися з декількох полів.

UNIQUE – ключ (індекс), задаючий поля, які можуть мати тільки унікальні значення.

INDEX – звичайний індекс (як ми описали вище). В MySqL, крім того, можна індексувати рядкові поля по заданому числу символів від початку рядка.

4 Субд MySql

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

Працювати з MySQL можна не тільки в текстовому режимі, але і в графічному. Існує дуже популярний візуальний інтерфейс (до речі, написаний на PHP) для роботи з цією СУБД. Називається він PhpMyAdmin. Цей інтерфейс дозволяє значно спростити роботу з базами даних в MySQL .

В текстовому режимі робота з базою даних виглядає просто як введення команд в командний рядок (рис 10.2), а результати вибірок повертаються у вигляді своєрідних таблиць, поля в яких налізають один на одного, якщо дані не поміщаються на екран (рис 10.3).

Мал. 10.2. Робота з MySQL в командному рядку. Команда show databases — вивести всі наявні бази даних

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

Мал. 10.3. Робота з MySQL в командному рядку. Результат обробки команди show databases

Перш ніж переходити до детального вивчення язика SQL, декілька слів про установку MySQL і підготовку до роботи. Якщо ви не збираєтеся займатися адмініструванням серверу, то інформація, приведена нижче, стане в нагоді вам тільки для загального розвитку. Отже, встановлюється MySQL дуже просто – автоматично, пару раз натискуйте OK, і все. Після цього ви можете зайти в директорію, де лежать файли типу mysql.exe, mysqld.exe і т.п. (у нас під Windows XP це С:\mysql\bin ) Останній файл запускає Mysql-сервер. В деяких системах сервер запускається у вигляді сервісу. Після запуску серверу слід запустити mysql-клієнт, запустившися програму mysql.exe. Тут навіть пароля не запитають. Більш того, якщо ви наберете

shell> mysql.exe -u root

або

shell>mysql -u root mysql

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

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

shell> mysql -u root mysql

mysql> UPDATE user SET Password=PASSWORD('new_password')

WHERE user='root';

mysql> DELETE FROM user WHERE user ='';

mysql> FLUSH PRIVILEGES;