На перший погляд може показатися, що потреба (те, що людині потрібно) і вираження цієї потреби на деякій мові — це те саме. Насправді це не так. Якщо людина чи знає почуває, що йому потрібно, то це ще не означає, що він може виразити свою потребу відповідною мовою. Уявіть собі, що ви спілкуєтеся з дитиною, що не вміє розмовляти, чи з іноземцем, що не знає вашої мови. Він лементом (дитина) чи жестом (іноземець) показує, що йому щось потрібно від вас. Але зрозуміти, що саме йому потрібно, ви не можете. А він же знає, що йому потрібно! Ви починаєте, пропонувати йому різні предмети, а він або відкидає, або приймає їх.

Відзначимо, до речі, що потреба користувача може бути і невимовна даною мовою. Уявіть собі, що ви намагаєтеся пояснити давньослов'янською мовою, що вам потрібний комп'ютер.

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

Довідка (Help) визначає запит так: “Вимога на добір даних, що зберігаються в таблицях, чи вимога на виконання визначених дій з даними. Запит дозволяє створити загальний набір записів з даних, що знаходяться в різних таблицях, і використовувати цей набір як джерело даних для чи форми звіту. У Microsoft Access користувач має можливість створювати і виконувати запити наступних типів:

· Запити на вибірку (включаючи запити з параметрами і підсумкові запити)

· Запити на зміну

· Перехресні запити

· Специфічні запити SQL.”

Запит на вибірку визначається в Help так: “Запит, у якому формулюються умови добору даних, що зберігаються в чи формі в об'єкті в режимі таблиці, і повертається набір записів, що задовольняє зазначеним умовам, без зміни даних, що повертається. Після висновку результатів запиту на екран стає можливим їхній перегляд, а в деяких випадках зміна даних у базових таблицях. На відміну від цього, у запитах на зміну виробляється зміна даних.”

Так що ж таке запит (і, зокрема, запит-вибірка): “спеціальна структура”, “вимога на добір даних”, “питання про даний”, “таблиця”, чи що-небудь інше?

Щоб відповісти на це питання, потрібно знову згадати, що в реляційних системах усі дані представляються у виді таблиць. Ці таблиці поділяються на базисні (тобто вихідні дані) і похідні, що обчислюються на основі базисних. Базисні відносини — це вихідні дані. А похідні — це або відповідь, або проміжні результати. Суть роботи СУБД полягає в тім, що вона, перетворити наявні відносини, будує по них нові відносини. Зрештою, обчислюється підсумкове відношення, що ми будемо називати відповіддю на запит.

Обмеження цілісності - це правила (можна сказати, аксіоми), що із усіх станів виділяють “розумні”. Наприклад, якщо в деякій базисній таблиці є атрибути “дата_народження” і “дата_смерті”, те природно ввести таке обмеження цілісності: дата_народження ? дата_смерті.

Визначимо стан БД як набір базисних відносин. (Більш точно було б визначити стан як алгебраїчну систему, але це ускладнило б формалізацію.) У класі всіх станів виділяється підклас припустимих станів. Це ті стани, що задовольняють обмеженням цілісності. Тоді запит можна трактувати як функцію Z, що зіставляє кожному припустимому стану ST деяке відношення Z(ST), що ми і називаємо відповіддю на запит. При цьому сам запит записується вираженням на відповідному формальній мові, що, як було вище сказане, називається мовою запитів. Це вираження ми будемо називати формулою запиту.

Пояснимо сказане на прикладі. Нехай мається два базисних відношення:

Розмови

номер | дата | місто | тривалість

11-22-33 | 01.01.00 | Москва | 7

11-22-33 | 01.02.00 | Париж | 9

22-33-44 | 01.01.00 | Женева | 20

22-33-44 | 02.01.00 | Цюрих | 17

і

Телефони

номер | власник | Адрес

11-22-33 | Іванов | Ленина 17

22-33-44 | Петров | Вайнера 4

Нас цікавить, з якими містами і коли розмовляв Петров. Для того, щоб вирахувати відповідь на цей запит, потрібно з’єднати таблиці Розмови і Телефони і вибрати з них всі рядки, які відповідають умовам власник = “Петров”, і забрати зайві колонки. В результаті отримаємо наступну таблицю:

Відповідь на запит

дата | місто

01.01.00 | Женева

02.01.00 | Цюрих

Зрозуміло, що якби базисні таблиці Розмови і Телефони мали інше наповнення, то і відповідь була б іншою. У цьому змісті ми і говоримо, що запит є функція, що співставляє відповідь кожному припустимому стану.

Отже, ми звели поняття запиту до поняття функції. Навіщо це зроблено? Адже можна було б вважати запит невизначуваним поняттям, пославшись на те, що в будь-якій теорії є вихідні, невизначувані поняття. Наша відповідь такий. По-перше, украй бажано, щоб число невизначуваних понять було зведено до мінімуму, причому невизначувані поняття повинні носити досить загальний, інтегративний характер, що дозволяє використовувати його в описі значного класу інших понять. І якщо їсти можливість звести одні понять до інших, те це потрібно зробити в явному виді. По-друге, наш підхід дозволяє формалізувати зв'язок таких понять, як запит, відповідь на запит і формула запиту.

Мова запитів

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