Организация Web-доступа до баз даних із використанням SQL-запросов

УПРАВЛІННЯ ОСВІТИ АДМИНИСТРАЦИИ ЛЕНІНСЬКОГО РАЙОНА.

Організація Web-доступа до баз даних із використанням SQL-запросов.

Виконавець: ВОЛКОВ Костянтин Володимирович учень 11Б класу МСОШ № 175.

Керівники: ФЕДОРОВ Леонід Миколайович директор Інформаційно-методичного центра.

Управління освіти адміністрації Ленінського района.

МОКРЯНСКИЙ Дмитро Георгійович методист Інформаційно-методичного центра.

Управління освіти адміністрації Ленінського района.

Екатеринбург.

Cодержание |Запровадження. |3 | |1. Причини і закінчилася історія створення мови запитів SQL. |6 | |1.1. Реляционные бази даних. Загальні поняття. |6 | |1.2. Взаємодія SQL і СУБД. |8 | |1.3. Стандарти SQL. Сьогоднішнє стан. |8 | |2. Технології, щоб забезпечити, web доступом до баз даних. |13 | |2.1. Принципи роботи SQL-сервера. |14 | |2.2. Таблиці SQL. |15 | |2.2.1. Структура запитів SQL. |16 | |2.2.2. Запити з допомогою єдиною таблиці SQL. |20 | |2.2.3. Запити із кількох таблиць SQL. |35 | |2.2.4 Модифікація даних в таблицях SQL. |55 | |2.3. Огляд основних SQL-серверов. |64 | |2.3.1. SQL-сервер Oralce. |67 | |2.3.2. Microsoft SQL сервер. |70 | |2.3.3. MySQL — сервер. |72 | |2.4. Принципи роботи web-серверов. |74 | |2.4.1. Web-сервер. Поняття, функції, характеристики. |74 | |2.4.2. Трехзвенная архітектура клієнт-сервер. |74 | |2.4.3. Архітектура Internet/Intranet. |75 | |2.4.4. Огляд серверних програм щодо різноманітних ОС. |77 | |2.4.5. Стандарти, які полегшують створення Web-узлов. |78 | |2.4.6. Web-технології. |79 | |2.4.7. Web-сервер Apache. |80 | |2.4.8. Web-сервер Jigsaw. |81 | |Web-сервер Netscape Enterprise. |82 | |Microsoft Internet Information Server. |87 | |2.5. Організація користувальницького інтерфейсу для доступу до |89 | |баз даних. | | |3. База даних Інформаційно-методичного центру «Дані |95 | |про освітні установи ». | | |4. Питання безпеки і санкціонування доступу до баз |100 | |даних. |104 | |5. Перспективи розвитку мережевих баз даних. |106 | |6. Список літератури. | | |Додатка (Лістинг програм). | |.

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

База даних — це, передусім, сховище об'єктів даних, тобто. набору можливих понять або негативних подій, описуваних базою даних, з можливістю пошуку цих об'єктів за ознаками. Невід'ємною рисою бази даних є можливість зв’язування об'єктів між собою. Базою даних вважатимуться як таблиці, индексирующие файли зі знаннями різних форматів, а й ці файли, оскільки є не типизированными сховищами знань у такий базі данных.

Отже, в базах знань ми накопичуємо досвід минулого. Потім то вона може сам прийняти зважене рішення з урахуванням цього досвіду (типовий випадок із мультимедійним довідником) чи поставити завдання перед базою даних із пошуку рішення відповідно до цій ситуації (знайти закон, поясняющий правило оформлення митної декларації тощо.). Так відбувається у програмах довідкового характеру. Як окреме питання баз даних, так можна трактувати різні структуровані файли, наприклад, словники для перекладачів, формати файлів RTF, DOC, книжки Microsoft Excel, файли з листами для поштових Internetпрограм тощо., життєво важливі функції баз даних, у яких реалізуються з допомогою внутрішніх функцій програм які працюють із ними. Бази даних можуть застосовуватися як допоміжного засобу, що дозволяє реалізувати якусь корисну функцію. Наприклад, зберігання настройок програми, Internet-адресов для розсилки реклами й т.д.

Структура інформаційних систем.

Для побудови інформаційних систем застосовуються бази даних, створені навколо ядра бази даних. Фундаментальна обізнаність із базою даних відбувається, як правило, в многопользовательском режимі, тобто. програма мусить бути мережевий. У зв’язку з цим, необхідно забезпечити поділ прав доступу різним користувачам до даних, правильність завершення транзакцій, тобто. ссылочную цілісність, обмеження та інші правила, реалізовані через вбудовані кошти серверу бази даних. До того ж, необхідно забезпечити прийнятна продуктивність інформаційної системи. У центрі всієї інформаційної системи стоїть сервер бази даних. Він забезпечує низкоуровневый доступом до таблицям бази даних, де й зберігається інформація про об'єкти бази даних. Ядром інформаційної системи в найпростішому разі, можуть виступати кілька функцій, реалізованих у програмі программистом.

У світі найчастіше застосовується сервер додатків для реалізації ядра інформаційної системи. У розподіленої обчислювальної системі сервер додатків перебирає функцію розподілу навантаження між серверами, які у загальному разі, можуть працювати під різними операційними системами, або у різних географічно місцях. Сервер додатків — це місток між програмами-клієнтами і одного чи кількома серверами бази даних. за рахунок серверу додатків можна знизити навантаження на докладання користувача і реалізувати складні правила об'єктної моделі бази даних, які важко чи нераціонально реалізовувати на боці серверу бази даних. Через війну, сервер додатків знижує трафік між сервером бази даних, і комп’ютером клієнта, підвищуючи загальну продуктивність інформаційної системи. З сказаного раніше, на додаток користувача залишається тільки реалізація інтерфейсу. Така структура інформаційної системи називається многозвенной, а додаток користувача — тонким клієнтом. Слід зазначити, що загалом разі сервери додатків можуть посилати команди одна одній, і взаємодіяти, таким чином, самим раціональним методом з географічно віддаленими серверами баз даних. Наприклад, щоб одержати звіту з велику кількість вычисляемых полів, не потрібно робити кілька запитів до віддаленій базі даних через Internet, якщо це може зробити сервер додатків, що у безпосередній близькості до серверу бази даних. Воно й пошле у відповідь готовий отчет.

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

Необхідні функції бази данных.

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

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

введення інформацію про одному об'єкті у різний спосіб чи різних местах;

введення одному й тому ж інформацією кількох местах;

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

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

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

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

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

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

Ще один зручна функція базі даних — це наскрізне проходження по документам.

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

Причини і розпочинається історія створення мови запитів SQL.

Реляционные бази даних. Загальні понятия.

Будь-яку структуру даних можна перетворити на просту двумерную таблицю. Це уявлення є найзручнішим й у користувача, й у машини, — переважна більшість сучасних інформаційних систем саме з такими таблицями. Бази даних, які з двовимірні таблиць, називаються реляционными.

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

З усіх систем баз даних реляционные ставляться до поширеним у світі. Ці системи здатні дозволити ті проблем, які ускладнювали роботи з нереляционными продуктами колишніх поколінь. Програмісти і адміністратори таких баз даних змушені були старанно вивчати, як структурована інформація, і як представленій у базі даних, значно ускладнило розробку цих додатків і модифікацію самих програм. Реляционные системи здатні працювати більш високому рівні. Усі операції з цими реалізуються програмою, званої DBMS (систему управління базою даних Звертатися до неї лише за допомогою операторів мови високого рівня. Хоча деякі продукти як і підтримують роботу у термінах власних мов, мову SQL (Standard Query Language) стала технологічним стандартом, з урахуванням якого створено всі, більш-менш відомі, реляционные продукты.

Мова для взаємодії з БД SQL виник середині 70-х і він розроблений у межах проекту експериментальної реляційної СУБД System R. Вихідний назва мови SEQUEL (Structered English Query Language) лише частково відбиває суть цієї мови. Звісно, мова була орієнтований головним чином на зручну і зрозумілу користувачам формулювання запитів до реляційної БД, але насправді був повним мовою БД, що містить крім операторів формулювання запитів і маніпулювання БД кошти ухвали і маніпулювання схемою БД. У мові були відсутні кошти синхронізації доступу до об'єктів БД із боку паралельно виконуваних транзакцій: від початку передбачалося, що необхідну синхронізацію неявно виконує СУБД.

У основі нових реляционных баз даних (і стандарту SQL) лежить кілька правив і принципов:

. Усі значення даних складаються з простих типів даних. У SQL відсутні масиви, покажчики, вектори та інші складні типи данных.

. Усі дані в реляційної базі даних зображуються у вигляді двовимірні таблиць (мовою математики — «відносин»). Кожна таблиця містить певна кількість рядків (зокрема 0), званих «картежами» і тільки чи кілька шпальт, званих «атрибутами». Усі рядки у таблиці мають те ж послідовність шпальт, у яких записані різні значення, проте набори значень в шпальтах отличаются.

На малюнку 1 приведено найпростіша таблиця такого типа.

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

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

. Оскільки неможливо визначити рядок з її становищу (порядку в таблиці), необхідно мати чи кілька шпальт з унікальним значенням для ідентифікації кожного рядка. Ці стовпчики називаються первинними ключами таблицы.

У прикладі на рис. 1 це перший столбец.

|ID |Ім'я |Телефон |Місто | |2 |Іван І |555−001 |Москва | |1 |Костянтин У. Волков |555−330 |Єкатеринбург | |3 |Василь У. Грабер |555−607 |Санкт-Петербург |.

Малюнок 1.

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

1.2. Взаємодія SQL і СУБД.

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

SQL став уніфікованим засобом спілкування, і стандартним мовою маніпулювання з базами даних, які мають коштів реалізації перелічених вищі за можливості. Після появи над ринком двох піонерських СУБД — SQL/DS (1981 рік) і DB2 (1983 рік) — він набув статусу стандарту дефакто для професійних реляционных СУБД. У 1987 року SQL став офіційним міжнародним стандартом мови баз даних, а 1992 року вийшов друга версія цього стандарта.

Важливою відмінністю SQL є його незалежність від комп’ютерної середовища (операційної системи й архітектури). Таку мову назвали SQL — це абревіатура структурованого мови запитів (Structured Query Language). SQL є інструментом, призначеним в обробці і читання інформації, котра міститься у комп’ютерній базі данных.

Під час створення мови запитів нової генерації розробники намагалися зробити його простою й легким лідера в освоєнні інструментом для звернення до БД. У результаті SQL став слабко структурованим мовою, особливо з порівнянню з такими мовами, як З чи Pascal, й те водночас досить потужним і щодо легким для изучения.

1.3. Стандарти SQL. Сьогоднішнє состояние.

Однією з найважливіших кроків шляху до визнанню SQL над ринком стало поява стандартів цей мову. Зазвичай на згадку стандарту SQL мають на увазі офіційний стандарт, затверджений Американським інститутом національних стандартів (American National Standards Institute — ANSI) і Міжнародної організацією за стандартами (International Standards Organization— ISO). Проте й інші важливі стандарти SQL, включаючи SQL, реалізований у системі DB2 компанії IBM, і стандарт X/OPEN для SQL серед UNIX.

Робота над офіційним стандартом SQL почалася 1982 року, коли ANSI поставив перед своїм комітетом ХЗН2 завдання створення стандарту мови реляционных баз даних. Спочатку у фінансовому комітеті обговорювалися гідності різних запропонованих мов. Та оскільки на той час SQL вже стало фактичним стандартом, комітет ХЗН2 зупинив свій вибір у ньому і нарешті зайнявся стандартизацією SQL.

Розроблений результаті стандарт значною мірою грунтувався на діалекті SQL системи DB2, хоч і містив у собі низку істотної різниці від рівня цього діалекту. Після кількох доробок, в 1986 року стандарт був офіційно було затверджено як стандарт ANSI номер Х3.135, а 1987 року — в ролі стандарту ISO. Потім стандарт ANSI/ISO було прийнято урядом США як федеральний стандарт США з обробки інформації (FIPS — Federal Information Processing Standard). Цей стандарт, незначно переглянутий 1989 року, зазвичай називають стандартом «SQL-89», чи «SQLI». Коли даному рефераті згадую «стандарт ANSI/ISO», то маю на увазі SQLI, який у даний час є основою більшості комерційних продуктов.

Чимало понять з членів комітетів по стандартизації ANSI і ISO представляли фірми-постачальники різних СУБД, у кожному з-поміж яких був реалізований власний варіант SQL. Як багато і діалекти людського мови, діалекти SQL були переважно схожі один на друга, проте несумісні докладно. У часто комітет просто обійшов існуючі розбіжності й не стандартизировал вік деяких частин мови, визначивши, що вони реалізуються по розсуду розробника. Такий підхід дозволив оголосити велика кількість реалізацій SQL сумісними зі стандартом, проте зробив сам стандарт щодо слабым.

Щоб заповнити ці прогалини, комітет ANSI продовжив діяти і створив проект нового, жорсткішого стандарту SQL2. На відміну від стандарту 1989 року, проект SQL2 передбачав можливості, котрі виступають поза рамки таких, вже що у реальних комерційних продуктах. Щодо наступного його стандарту SQL3 було запропоновано ще більше глибокі зміни. Через війну запропоновані стандарти SQL2 і SQL3 виявилися суперечливими, ніж вихідний стандарт. Стандарт SQL2 пройшов процес затвердження в ANSI і він остаточно прийнятий у жовтні 1992 року. Тоді, як стандарт 1986 року займає трохи більше ста сторінок, офіційний стандарт SQL2 містить близько шестисот.

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

Хоча стандарт ANSI/ISO найширше поширений, вона є єдиним стандартом SQL. Європейська група постачальників X/OPEN також прийняла SQL як один зі своїх стандартів для «середовища які додатків» з урахуванням UNIX. Стандарти групи X/OPEN відіграють істотне значення на європейському комп’ютерному ринку, де основний проблемою є перенесення додатків між комп’ютерними системами різних виробників. На жаль, стандарт X/OPEN відрізняється від стандарту ANSI/ISO.

З іншого боку, компанія IBM включила SQL на свій специфікацію Systems Application Architecture (архітектура прикладних систем) і пообіцяла, що її продукти, очевидно, буде переведено цей діалект SQL. Хоча дана специфікація і виправдала сподівань на уніфікацію лінії продуктів компанії IBM, спрямування бік уніфікації SQL в IBM триває. Система DB2 залишається основний СУБД компанії IBM для мэйнфреймов. Проте компанія випустила реалізацію DB2 й у OS/2 (власною операційною системи для персональних комп’ютерів), й у лінії серверів і тимчасових робочих станцій RS/6000, працюючих під керівництвом UNIX. Отже, діалект DB2 мови SQL є потужною стандартом де-факто.

У технології баз даних існує важлива область, що її зачіпають офіційні стандарти. Це спроможність до взаємодії з іншими базами даних — методи, з допомогою яких різні БД можуть обмінюватися інформацією (зазвичай, через мережу). У 1989 року кілька постачальників сформували консорціум SQL Access Group спеціально на вирішення цієї проблеми. У 1991 року консорціум опублікував специфікацію RDA (Remote Database Access — віддалений доступом до баз даних). Ця специфікація тісно пов’язані з протоколами OSI, які змогли завоювати широке пошанування, тому вона надає ринку незначне вплив. Прозорість взаємодії між різними базами даних залишається ілюзорною мечтой.

Проте, другий стандарт від SQL Access Group тримає в ринку більший вагу. Через війну наполегливих вимог компанії Microsoft, консорціум SQL Access Group увімкнув у стандарт SQL інтерфейс викликів функцій. Отримана специфікація CLI (Call Level Interface), джерело якої в розробках компанії Microsoft, побачила світ 1992 року. У цьому року було опублікована власна специфікація ODBC (Open Database Connectivity — взаємодія з відкритими базами даних) компанії Microsoft, джерело якої в стандарті CLI. Завдяки ринкову силу Microsoft і благословенню, одержаному «відкритим стандартом» від SQL Access Group, ODBC виявився стандартом де-факто для інтерфейсів доступу до баз даних на персональні комп’ютери. Навесні 1993 року компанії Apple і Microsoft оголосили угоди щодо підтримки ODBC в MacOS і Windows, що закріпило цю спецификацией статус стандарту на обох популярних середовищах з графічним користувальницьким интерфейсом.

Поява стандарту SQL викликало значна частина захоплених заяв про переносимості SQL і використовують його додатків. Насправді прогалини у стандарті SQL-89 і відмінності між існуючими діалектами SQL досить значні, і за перекладі додатка за іншу СУБД його завжди доводиться модифікувати. Ці відмінності, більшість із яких усунуто в стандарті SQL2, беруть у себя:

Коди помилок. У стандарті SQL-89 не визначено коди, які повертають оператори SQL у разі виникнення помилок, в кожній з комерційних реалізацій використовується власний набір таких кодів. У стандарті SQL2 визначено стандартні коди ошибок.

Типи даних. У стандарті SQL-89 визначено мінімальний набір типів даних, проте, у ньому відсутні що з найпоширеніших і корисних типів, наприклад символьні рядки перемінної довжини, дата та палестинці час, і навіть грошові одиниці. У стандарті SQL2 згадані ці типи даних, проте, відсутні «нові» типи даних, такі як графічні і мультимедійні объекты.

Системні таблиці. У стандарті SQL-89 замовчується про системних таблицях, які містять інформацію про структурі самої бази даних. Тому кожен постачальник створював власні системні таблиці, та його структура відрізняється навіть у чотирьох реалізаціях SQL компанії IBM. Системні таблиці стандартизированы в SQL2.

Інтерактивний SQL. У стандарті визначено лише програмний SQL, використовуваний прикладної програмою, але з інтерактивний SQL. Наприклад, оператор select, готовий до виконання запитів до бази даних в інтерактивному режимі, у стандарті отсутствует.

Програмний інтерфейс. У першому стандарті визначено абстрактний спосіб використання SQL програми, написаних мовами програмування, як COBOL, FORTRAN та інші. Такий спосіб немає в жодному комерційному продукті, а існуючих програмних інтерфейсах є чималі відмінності. У стандарті SQL2 визначено інтерфейс вмонтованого SQL для популярних мов програмування, але з інтерфейс виклику функций.

Динамічний SQL. У стандарті SQL-89 не описані елементи SQL, необхідних розробки додатків загального призначення, як-от генератори звітів і програми створення і виконання запитів. Але ці елементи, відомі під назвою динамічний SQL, є майже переважають у всіх СУБД й у різноманітних системах значно різняться. У SQL2 входить стандарт динамічного SQL.

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

Послідовність порівняння. У стандарті SQL-89 не згадуються послідовності порівняння (сортування) символів, які у базі даних. Результати запиту з сортуванням різнитимуться і під час цього запиту на персональному комп’ютері (з кодуванням ASCII) і мэйнфрейме (з кодуванням EBCDIC). Стандарт SQL2 дозволяє програмі чи користувачеві вказувати необхідну послідовність сортировки.

Структура бази даних. У стандарті SQL-89 визначено SQL, який використовується вже по тому, як даних було відкрито й добре підготовлено до роботі. Деталі найменування баз даних, і початкового підключення до них дуже відрізняються і несумісні. Стандарт SQL2 певною мірою уніфікує той процес, однак може повністю ліквідувати все отличия.

Всупереч переліченим розбіжностям, на початку 1990;х років почали з’являтися комерційні програми, реалізують перенесення додатків між різними СУБД. Однак у таких програмах кожної з підтримуваних СУБД потрібен спеціальний конвертер, який генерує код згідно з певним діалектом SQL, виконує перетворення типів даних, транслює коди помилок, і т.д. «Прозора» перенесення між різними СУБД, використовуючи SQL, є основним метою стандарту SQL2 і протоколу ODBC. Проте повсюдний, «прозорий» і уніфікований доступом до баз даних SQL залишається справою будущего.

Технології, щоб забезпечити мережевий доступом до баз данных.

Світове павутиння недарма буде настільки швидким завоювала широку популярність серед користувачів Internet, у світі бізнесу, науки, політики тощо. буд. Основні досягнення Web — це простота опублікування інформацією мережі, зручність і порівняльна уніфікованість доступу до документів, наявність на сьогодні достатньо розвинутих коштів пошуку. Однак у цілому способи уявлення, збереження і пошуку інформацією WWW ставляться до категорії інформаційно-пошукових систем (ИПС). Хоча сховища даних в вузлах Web іноді називають базами даних, цей термін у разі можна використовувати аж у широкому значенні. Історично ИПС застосовувалися для зберігання слабоструктурированной і рідко змінюваного інформації. Бази даних у вузькому значенні - це сховища структурованої, змінюваного інформації, причому інформація базі даних повинна завжди перебувати у узгодженому состоянии.

З рівним успіхом можна хвалити і лаяти Web. Можна хвалити Всесвітню Павутиння через те, що, виходячи з дому, ви можете побувати у будь-якій точці земної кулі і подивитися, що саме відбувається. Можна лаяти Web через те, що важко знайти справді актуальну інформацію (зазвичай вона застаріла), через те, що сховища інформації містять дуже багато «сміття», опублікованого незрозуміло з яких міркувань. Але за будь-якого разі інтерфейс справді удобен.

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

Отже, маємо зручні кошти розробки розподілених в Internet гипермедийных документів, прості, зручні, розвинені і уніфіковані інтерфейси для доступу до інформації WWW. З іншого боку, маємо велике кількість цінних баз даних, керованих різнорідними СУБД, і навіть бажання ці бази доступними всіх людей (у разі публічних баз даних) чи членам территориально-распределенной корпорації (у разі корпоративних баз даних). Виникає природне бажання схрестити ці дві технологій і забезпечити доступом до баз даних в інтерфейсі Web. Ще двоє роки тому були тільки ідеї такого схрещування не дуже старанно розроблені підходи до реалізації. Сьогодні такі механізми вже є і используются.

1 Принципи роботи SQL-сервера.

SQL є інструментом, призначеним в обробці читання даних, які у комп’ютерної базі даних. SQL (структурований мову запитів) як міститься в назві, є мовою програмування, що застосовується організації взаємодії користувача з базою даних. Насправді SQL працює тільки з базами даних одного певного типу, званих реляционными.

Малюнок 2.1.

На малюнку 2.1 зображено схема роботи SQL. Відповідно до таку схему, в обчислювальної системі є база даних, у якій зберігається важлива інформація. Якщо БД належить до сфери бізнесу, то ній може зберігатися інформацію про матеріальні цінності, своєї продукції, обсягах продажів та середній зарплаті. У базі даних на персональному комп’ютері може зберігатися інформацію про виписаних чеках, телефонах і адреси чи інформація, викопана з більшої обчислювальної системи. Комп’ютерна програма, який управляє базою даних, називається системою управління базою даних, чи СУБД. Якщо користувачеві необхідно прочитати дані з даних, він затребувана їх в SQL з допомогою СУБД. SQL обробляє запит, знаходить необхідні дані і посилає їх користувачеві. Процес запрашивания даних, і отримання результату називається запитом до бази даних: тому й назва — структурований мову запитів. Але це назва ні чи реальні. Cегодня SQL є щось значно більше, ніж простий інструмент створення запитів, хоча саме цього він був спочатку призначений. Попри те що, що читання даних продовжує залишатися однією з найбільш важливих функцій SQL, сьогодні це мову використовується для реалізації всіх функціональних можливостей, які СУБД надає користувачеві, а саме:. Організація даних. SQL дає користувачеві можливість змінювати структуру уявлення даних, і навіть встановлювати відносини між елементами бази даних.. Читання даних. SQL дає користувачеві чи додатку можливість читати з даних які у ній дані і користуватися ними.. Обробка даних. SQL дає користувачеві чи додатку можливість змінювати базі даних, тобто. додавати у ній нові дані, і навіть видаляти чи оновлювати вже що у ній дані.. Управління доступом. З допомогою SQL можна обмежити можливості користувача читання і зміни даних, і захистити їхнього капіталу від несанкціонованого доступу.. Спільне використання даних. SQL координує спільного використання даних користувачами, які працюють паралельно, що вони не заважали одна одній.. Цілісність даних. SQL дозволяє забезпечити цілісність бази даних, захищаючи його від руйнації через неузгоджених змін чи системы.

Отже, СУБД є дуже потужним засобом взаємодії з SQL.

Основними об'єктами реляційної бази даних являются:

(TABLE) Таблица.

Прямокутна таблиця, що складається з РЯДКІВ і ШПАЛЬТ. Поставити таблицю — отже вказати, з яких шпальт вона состоит.

(ROW) Строка.

Запис, що складається з полів — шпальт. У кожному полі міститься його значення, або значення NULL — «порожньо». Строк в таблиці то, можливо скільки завгодно. Фізичний порядок їхнього розташування друг щодо друга неопределен.

(COLUMN) Столбец.

Кожен стовпець в таблиці має власні ім'я і тип.

1 Таблиці SQL.

У реляційної базі даних інформація організована вигляді таблиць, розділених на рядки — і стовпчики, на перетині яких значення даних. Використовувані у мові SQL для запитів поєднання ключів (CREATE TABLE my_table — створення таблиці під назвою my_table) дістали назву «пропозицію». Таблиці створюють у SLQ з допомогою пропозиції CREATE TABLE. Пропозиція CREAT TABLE специфицирует ім'я базової таблиці, які мають сформуватися, імена її шпальт і типи даних тих шпальт. CREAT TABLE — яке виконує пропозицію. Якщо SQL-серверу дати запит CREATE TABLE, система побудує таблицю, що спочатку буде порожній: вона утримувати лише рядок заголовків шпальт, але не ще утримувати ніяких рядків з цими. Інформація в таблицю вставляється з допомогою пропозиції команди INSERT.

1 Структура запитів SQL.

Усі запити отримання практично будь-яких даних із однієї або кількох таблиць виконуються з допомогою єдиного пропозиції SELECT. У синтаксичних конструкціях для звернення до БД використовуються такі обозначения:

1. зірочка (*) для позначення «все» — вживається у звичайному для програмування сенсі, тобто. «всі випадки, задовольняють определению»;

2. квадратні дужки ([]) — означають, що конструкції, укладені ці дужки, необов’язкові (тобто. може бути опущены);

3. фігурні дужки ({}) — означають, що конструкції, укладені ці дужки, мають розглядатися як цілі синтаксичні одиниці, тобто. вказують уточнити порядок розбору синтаксичних конструкцій, замінюючи звичайні дужки, використовувані в синтаксисі SQL;

4. крапки (…) — зазначає, що безпосередньо попередня йому синтаксична одиниця факультативно може повторюватися чи більш раз;

5. пряма риса (|) — означає наявність вибрати з двох чи більше можливостей. Наприклад, позначення ASC|DESC вказує, можна вибрати одне із термінів ASC чи DESC; а коли одне із елементів вибору полягає у квадратні дужки, це означатиме, що він вибирається за умовчанням (так, [ASC]|DESC означає, що відсутність цієї конструкції сприйматиметься як вибір ASC);

6. точка з коми (;) — завершальний елемент пропозицій SQL;

7. кома (,) — використовується потреби ділити елементів списков;

8. прогалини () — можуть вводитися підвищення наочності між будь-якими синтаксичними конструкціями пропозицій SQL;

9. жирні прописні латинські букви і символи — йдуть на написання конструкцій мови SQL і дружина мають (якщо це спеціально не обумовлено) записуватися з точністю оскільки показано-…; 10. рядкові літери йдуть на написання конструкцій, які мають замінюватись конкретними значеннями, обраними користувачем, причому для визначеності окреме слово цих конструкцій зв’язуються між собою символом підкреслення (_); 11. терміни «таблиця» і «стовпець» заміняють (з метою зменшення тексту синтаксичних конструкцій) терміни «имя_таблицы», «имя_столбца», …, відповідно; 12. термін «таблиця» — використовується для узагальнення таких видів таблиць, як базовая_таблица, уявлення чи псевдонім; тут псевдонім служить для тимчасового (на даний момент виконання запиту) перейменування і (чи) створення робочої копії базовой_таблицы (уявлення). Пропозиція SELECT (вибрати) має наступний формат:

подзапрос [UNION [ALL] подзапрос] … [ORDER BY {[таблица.]столбец | номер_элемента_SELECT} [[ASC] | DESC] [,{[таблица.]столбец | номер_элемента_SELECT} [[ASC] | DESC]] …;

и дозволяє об'єднати (UNION) та був впорядкувати (ORDER BY) результати вибору даних, отриманих з допомогою кількох «подзапросов». У цьому впорядкування можна робити гаразд зростання — ASC (ASCending) чи зменшення DESC (DESCending), а, по вмовчанням приймається ASC. У цьому вся пропозиції подзапрос дозволяє вказати умови для вибору потрібних даних, і (якщо потрібно) їх опрацювання SELECT.

(вибрати) дані із зазначених шпальт і (якщо потрібно) виконати перед висновком їх перетворення на відповідність до зазначеними висловлюваннями и.

(чи) функціями FROM.

(з) перелічених таблиць, де розташовані ці стовпчики WHERE.

(де) рядки зазначених таблиць повинні задовольняти зазначеному переліку умов відбору рядків GROUP BY.

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

SELECT SQL-функции SUM (сума), COUNT (кількість), MIN (мінімальне значення), MAX (максимальне значення) чи AVG (середнє) HAVING.

(маючи) у результаті тільки ті групи, які задовольняють зазначеному переліку умов відбору груп і має формат SELECT [[ALL] | DISTINCT]{ * | элемент_SELECT [, элемент_SELECT] …} FROM {базовая_таблица | уявлення} [псевдоним].

[,{базовая_таблица | уявлення} [псевдонім]] … [WHERE фраза] [GROUP BY фраза [HAVING фраза]];

Элемент_SELECT — це одне з наступних конструкций:

[таблица.]* | значення | SQL_функция | системная_переменная де значення — це: [таблица.]столбец | (вираз) | константа | переменная.

Синтаксис висловів має вид.

({[ [+] | - ] {значення | функция_СУБД} [ + | - | * | ** ]}…).

а синтаксис SQL_функций — одне з наступних конструкций:

{SUM|AVG|MIN|MAX|COUNT} ([[ALL]|DISTINCT][таблица.]столбец).

{SUM|AVG|MIN|MAX|COUNT} ([ALL] вираз).

COUNT (*).

Фраза WHERE включає набір умов відбору строк:

WHERE [NOT] WHERE_условие [[AND|OR][NOT] WHERE_условие]… де WHERE_условие — одне з наступних конструкцій: значення { = | | < | | >= } { значення | (подзапрос) }.

значение₁ [NOT] BETWEEN значение₂ AND значение₃.

значение [NOT] IN { (константа [, константа]…) | (подзапрос) }.

значение IS [NOT] NULL.

[таблица.]столбец [NOT] LIKE «строка_символов «[ESCAPE «символ «].

EXISTS (подзапрос).

Крім традиційних операторів порівняння (= | | < | | >=) в WHERE фразі використовуються умови BETWEEN (між), LIKE (схоже), IN (належить), IS NULL (не визначено) і EXISTS (існує), що потенційно можуть випереджатися оператором NOT (не). Критерій відбору рядків формується з однієї чи кількох умов, з'єднаних логічними операторами: AND 1. коли повинні задовольнятися обидва поділюваних з допомогою AND умови; OR 2. коли має задовольнятися одна з поділюваних з допомогою OR умов; AND NOT 3. коли має задовольнятися першу умову й не друге; OR NOT 4. коли чи має задовольнятися першу умову або має задовольнятися друге, причому існує пріоритет AND над OR (спочатку виконуються усі фінансові операції AND і після цього операції OR). Для отримання бажаного результату WHERE умови повинні бути введені в правильному порядку, що можна організувати запровадженням скобок. Після обробітку умови числа порівнюються алгебраїчно — негативні числа вважаються меншими, ніж позитивні, незалежно від своїх абсолютної величини. Рядки символів порівнюються відповідно до їх поданням до коді, використовуваному у певній СУБД, наприклад, в коді ASCII. Якщо порівнюються два рядки символів, мають різні довжини, більш коротка рядок доповнюється справа прогалинами у тому, щоб вони мали однакову довжину перед здійсненням порівняння. Нарешті, синтаксис фрази GROUP BY має вид.

GROUP BY [таблица.]столбец [,[таблица.]столбец] … [HAVING фраза].

GROUP BY ініціює перекомпонування формованої таблиці за групами, кожна з яких має однакове значення в столб-цах, включених до переліку GROUP BY. Далі до цих групам застосовуються агрегирующие функції, зазначені у фразі SELECT, що зумовлює заміні всіх значень групи на єдине значення (сума, кількість тощо.). З допомогою фрази HAVING (синтаксис якої майже не від синтаксису фрази WHERE).

HAVING [NOT] HAVING_условие [[AND|OR][NOT] HAVING_условие]…

можно вилучити з результату групи, не задовольняють заданим условиям:

значение { = | | < | | >= } { значення | (подзапрос).

| SQL_функция }.

{значение₁ | SQL_функция₁} [NOT] BETWEEN.

{значение₂ | SQL_функция₂} AND {значение₃ | SQL_функция₃}.

{значение | SQL_функция} [NOT] IN { (константа [, константа]…).

| (подзапрос) }.

{значение | SQL_функция} IS [NOT] NULL.

[таблица.]столбец [NOT] LIKE «строка_символов «[ESCAPE «символ «].

EXISTS (подзапрос).

2.2.2. Запити з допомогою єдиною таблицы.

Вибірка без використання фрази WHERE.

Проста выборка.

Запит видати назва, статусу і адресу поставщиков.

SELECT Назва, Статус, Адреса FROM Постачальники; дає результат, наведений на рис. 2.2,а.

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

SELECT ПС, Назва, Статус, Місто, Адреса, Телефон FROM Постачальники; або використати бодай його коротку нотацию:

SELECT * FROM Поставщики;

Тут «зірочка» (*) служить коротким позначенням всіх імен полів в таблиці, зазначеної у фразі FROM. У цьому порядок виведення полів відповідає порядку, у якому ці поля визначалися під час створення таблиці. Ще одна приклад. Видати основу всіх блюд:

SELECT Основа FROM Страви; дає результат, показаний на рис. 2.2,б.

|а) | | |б) |в) | |Назва |Статус |Адреса |Основа |Основа | | | | |Овочі |Кава | | | | |М'ясо |Крупа | |СИТНИЙ |Ринок |Сытнинская,|Овощи |Молоко | | | |3 | | | |ПОРТОС |Кооператив |Садова, 27|Рыба |М'ясо | |ШУШАРЫ |Радгосп |Нова, 17 |Риба |Овочі | |ТУЛЬСЬКИЙ |Універсамам |Тульська, 3|Мясо |Риба | |ВРОЖАЙ |Коопторг |Піщана, |Молоко |Фрукти | | | |19 | | | |ЛІТО |Агрофірма |Пулковское |Молоко |Яйця | | | |ш., 8 | | | |ОГІРОЧОК |Ферма |Укмерге, 15|… | | |КОРЮШКА |Кооператив |Нарвское |Кава | | | | |ш., 64 | | |.

Малюнок 2.2.

Виняток дубликатов.

У минулому прикладі було видано правильний, але зовсім вдалий перелік основних продуктів: потім із нього були виключені дублікати. Для винятку дублікатів і одночасного упорядкування переліку необхідно доповнити запит ключовим словом DISTINCT (різний, різні), як показано наступного примере:

SELECT DISTINCT Основа FROM Страви; Результат наведено на рис. 2.2,в.

Вибірка вычисляемых значений.

З синтаксису фрази SELECT видно, що можуть утримувати не лише перелік шпальт таблиці чи символ *, а й выражения.

Наприклад, якщо потрібно одержати значення калорійності всіх продуктів, то можна врахувати, що з окислюванні 1 р вуглеводів чи білків в організмі звільняється загалом 4.1 Ккал, а при окислюванні 1 р жирів — 9.3 Ккал, і видати запрос:

SELECT Продукт, ((Белки+Углев)*4.1+Жиры*9.3) FROM Продукти; результат якого наведено на рис. 2.3,а. |а) | |Б) | | |в) | |Продукт | |Продукт | | |Продукт | | |Говядина|1928.1 |Говядина|Калорий |1928.1 |Зелень |118.9 | | | | |= | | | | |Судак |1523. |Судак |Калорій |1523. |Помидоры|196.8 | | | | |= | | | | |Олія |8287.5 |Олія |Калорій |8287.5 |Морква |349.6 | | | | |= | | | | |Майонез |6464.7 |Майонез |Калорій |6464.7 |Цибулю |459.2 | | | | |= | | | | |Яйця |1618.9 |Яйця |Калорій |1618.9 |Яблука |479.7 | | | | |= | | | | |Сметана |3011.4 |Сметана |Калорій |3011.4 |Молоко |605.1 | | | | |= | | | | |Молоко |605.1 |Молоко |Калорій |605.1 |Кава |892.4 | | | | |= | | | | |Сир |1575. |Сир |Калорій |1575. |Судак |1523. | | | | |= | | | | |Морква |349.6 |Морква |Калорій |349.6 |Сир |1575. | | | | |= | | | | |Цибулю |459.2 |Цибулю |Калорій |459.2 |Яйця |1618.9 | | | | |= | | | | |Помидоры|196.8 |Помидоры|Калорий |196.8 |Говядина|1928.1 | | | | |= | | | | |Зелень |118.9 |Зелень |Калорій |118.9 |Сметана |3011.4 | | | | |= | | | | |Рис |3512.1 |Рис |Калорій |3512.1 |Рис |3512.1 | | | | |= | | | | |Борошно |3556.7 |Борошно |Калорій |3556.7 |Борошно |3556.7 | | | | |= | | | | |Яблука |479.7 |Яблука |Калорій |479.7 |Цукор |4091.8 | | | | |= | | | | |Цукор |4091.8 |Цукор |Калорій |4091.8 |Майонез |6464.7 | | | | |= | | | | |Кава |892.4 |Кава |Калорій |892.4 |Олія |8287.5 | | | | |= | | | |.

Малюнок 2.3.

Фраза SELECT може охоплювати як висловлювання, а й окремі числові чи текстові константи. Слід зазначити, що текстові константи мають укладатися в апострофи («). На рис. 2.3,б наведено результат запроса:

SELECT Продукт, «Калорій = «, ((Белки+Углев)*4.1+Жиры *9.3) FROM Продукты;

Хіба станеться, якщо якийсь член висловлювання невизначений, тобто. має значення NULL і як з’явилося таке значение?

Якщо за завантаженні рядків таблиці у будь-якій з впроваджуються рядків відсутня значення для будь-якого шпальти, то СУБД запровадить у таке полі NULL-значение. NULL-значение «придумано» у тому, аби уявити єдиним чином «невідомі значення» для будь-яких типів даних. Справді, так як із введення даних в стовпець чи його зміні СУБД забороняє введення значень які відповідають опису даних цього шпальти, то, наприклад, не можна використовувати прогалину для відсутнього значення числа. Не можна для цього використовувати й нуль: немає місяця або дня тижня рівного нулю, так й у чисел нуль неспроможна розглядатися як невідоме значення щодо одного місці й як відоме — й інші. При виведення ж NULL-значения на екран чи друкарка його код відтворюється будь-яким спеціально заданим символом чи набором символів: наприклад, прогалиною (якщо його не можна переплутати їх з текстовим значенням прогалини) чи поєднанням -0-.

З допомогою спеціальної команди можна встановити СУБД одне із режимів уявлення NULL-значений і під час числових розрахунків: заборону або дозвіл заміни NULL-значения нулем. У першому випадку будь-яке арифметичне вираз, що містить невизначений операнд, буде також мати невизначене значення. У другий випадок результат обчислень матиме чисельна значення (якщо це значення потрапляє у діапазон уявлення відповідного типу даних). Наприклад, і під час запроса.

SELECT ПР, Ціна, К_во, (Ціна * К_во) FROM Поставки; і різноманітних «настроюваннях» СУБД можна отримати різні виходять результати: |ПР|Цена |К_во |(Цена*К_во) |ПР|Цена |К_во |(Цена*К_во) | |9 |-0- |-0- |-0- |9 |-0- |-0- |0. | |11|1.5 |50 |75. |11|1.5 |50 |75. | |12|3. |10 |30. |12|3. |10 |30. | |15|2. |170 |340. |15|2. |170 |340. |.

Використання BETWEEN.

З допомогою BETWEEN … AND … (перебуває у інтервалі від … до …) можна відібрати рядки, у яких значення будь-якого шпальти перебувають у заданому диапазоне.

Наприклад, видати перелік продуктів, у яких значення змісту білка перебуває у діапазоні від 10 до 50: | |Результат: | | | | | | |SELECT Продукт, | | | |Бєлки | | | |FROM Продукти | | | |WHERE Бєлки | | | |BETWEEN 10 AND | | | |50; | | | | |Продукт |Бєлки | | |Майонез |31. | | |Сметана |26. | | |Молоко |28. | | |Морква |13. | | |Цибулю |17. |.

Можна поставити і NOT BETWEEN (не належить діапазону між), наприклад: | |Результа| | | |т: | | | | | | |SELECT Продукт, | | | |Бєлки, Жири | | | |FROM Продукти | | | |WHERE Бєлки NOT | | | |BETWEEN 10 AND 50| | | | | | | |AND Жири 100; | | | | |Продукт |Бєлки |Жири | | |Говядина|189. |124. | | |Олія |60. |825. | |Яйця |127. |115. | |.

BETWEEN особливо зручний під час роботи з цими, задаваемыми інтервалами, початок і поклала край яких лежить у різних столбцах.

Наприклад скористаємося таблицею «мінімальних окладів» (табл. 2.4), розмір яких безпосередньо зі студентської стипендією. У цьому таблиці для поточного значення мінімального окладу встановлено позамежна дата закінчення 9 вересня 9999 года.

|Миноклад |Початок |Кінець | |2250 |01−01−1993 |31−03−1993 | |4275 |01−04−1993 |30−06−1993 | |7740 |01−07−1993 |30−11−1993 | |14 620 |01−12−1993 |30−06−1994 | |20 500 |01−07−1994 |09−09−9999 |.

Малюнок 2.4.

Якщо, наприклад, знадобилося дізнатися, які зміни мінімальних окладів проводилися в 1993/94 навчального року, можна видати запрос.

SELECT Початок, Миноклад FROM Миноклады WHERE Початок BETWEEN «1−9-1993 «AND «31−8-1994 «й одержати результат: |Початок |Миноклад | |01−12−1993 |14 620 | |01−07−1994 |20 500 |.

Зазначимо, що з формуванні запитів значення дат слід укладати в апострофи, щоб СУБД не плутала його з висловлюваннями не намагалася вичитати з 31 значення 8, та був 1994.

Для виявлення всіх значень мінімальних окладів, що існували в 1993/94 навчального року, можна сформувати запрос.

SELECT * FROM Миноклады WHERE Початок BETWEEN «1−9-1993 «AND «31−8-1994 «OR Кінець BETWEEN «1−9-1993 «AND «31−8-1994 «|Миноклад |Початок |Кінець | |7740 |01/07/1993|30/11/1993 | |14 620 |01/12/1993|30/06/1994 | |20 500 |01/07/1994|09/09/9999 |.

Нарешті, щоб одержати мінімального окладу на 15−5-1994: | |Результат: | | | |Миноклад | |SELECT Миноклад | | |FROM Миноклады | | |WHERE «15−05−1994 «| | |BETWEEN Початок AND | | |Кінець | | | |14 620 |.

Використання IN.

Видати інформацію про стравах з урахуванням яєць, крупи і овощей.

SELECT * FROM Страви WHERE Основа IN (Яйця Крупа Овочі); Результат: |БЛ|Блюдо |В|Основа |Вихід |Праця | |1 |Салат літній |З|Овощи |200. |3 | |3 |Салат вітамінний |З|Овощи |200. |4 | |16|Драчена |Г|Яйца |180. |4 | |17|Морковь з рисом |Г|Овощи |260. |3 | |19|Омлет з цибулею |Г|Яйца |200. |5 | |20|Каша рисова |Г|Крупа |210. |4 | |21|Пудинг рисовий |Г|Крупа |160. |6 | |23|Помидоры з цибулею |Г|Овощи |260. |4 |.

Розглянута форма IN в дійсності просто короткої записом послідовності окремих порівнянь, з'єднаних операторами OR. Попереднє пропозицію еквівалентно такому:

SELECT * FROM Страви WHERE Основа=Яйца OR Основа=Крупа OR Основа=Овощи;

Використання LIKE Видати перелік салатів | |Результат: | | | |Страва | |SELECT Страва | | |FROM Страви | | |WHERE Страва LIKE | | | «Салат% »; | | | |Салат літній | | |Салат м’ясної | | |Салат вітамінний | | |Салат рибний |.

Звичайна форма «имя_столбца LIKE текстовая_константа» для шпальти текстового типу дозволяє відшукати все значення зазначеного шпальти, відповідні зразком, заданому «текстовой_константой». Символи цієї константи інтерпретуються наступним чином: символ _ (підкреслення) — заміняє будь-який одиночний символ, символ % (відсоток) — заміняє будь-яку послідовністю N символів (де N то, можливо нулем), й інші символи означають просто самі себя.

Отже, у наведеному прикладі SELECT здійснюватиме вибірку записів з таблиці Страви, котрим значення в стовпці Страва починається поєднанням «Салат «і має будь-яку послідовністю нуля або як символів, наступних за поєднанням «Салат ». Якби серед страв були «Цибульний салат», «Фруктовий салат» тощо., то не було б знайдено. Для їх відшукання треба змінити фразу WHERE:

WHERE Страва LIKE «%салат% «або за відсутності різниці між малими великими літерами (таку настроювання допускають деякі СУБД):

WHERE Страва LIKE «%Салат% «Це дозволить відшукати все салаты.

Залучення невизначеного значення (NULL-значения).

Якщо за завантаженні даних не введено значення в якесь полі таблиці, то СУБД розмістить до нього NULL-значение. Аналогічне значення можна вводити на полі таблиці, виконуючи операцію зміни даних. Так, при відсутності даних про у постачальників судаки й моркви в стовпчики Ціна і К_во відповідних рядків таблиці Поставки вводиться NULL де він буде зберігатися код NULL-значения, а чи не 0, 0. Або прогалину. (Зазначимо, що у роздруківці таблиці Поставки у цих місцях розташований прогалину, встановлений в СУБД до подання NULL-значения при виведення на печатку). І тут виявлення назв продуктів, відсутніх у клуні, шеф-кухар може дати запит |Результат: |ПР | |P.S| |2 | |E| |9 | |L| | | |E| | | |З| | | |T| | | |D| | | |I| | | |P.S| | | |T| | | |I| | | |N| | | |З| | | |T| | | |П| | | |Р| | | | | | | |F| | | |R| | | |O| | | |M| | | |М| | | |а| | | |л| | | |і| | | |год| | | |і| | | |е| | | | | | | |W| | | |H| | | |E| | | |R| | | |E| | | |До| | | |_| | | |в| | | |про| | | |I| | | |P.S| | | |N| | | |U| | | |L| | | |L| | | |;| | |.

Природно, що з виявлення продуктів, що у комори, слід надати запрос.

SELECT DISTINCT ПР FROM Наявність WHERE К_во IS NOT NULL; Використання условий столбец IS NULL і стовпець IS NOT NULL замість, например, столбец = NULL і стовпець < NULL пов’язана з тим, що нічого — і навіть саме NULL-значение — не вважається рівним іншому NULL-значению. (Попри це, два невизначених значення розглядаються, проте, як дублікати одна одну виключення дублікатів, і пропозиції SELECT DISTINCT дасть внаслідок трохи більше одного NULL-значения.).

Вибірка з упорядочением.

Найпростіший варіант цієї фрази — впорядкування рядків результату по значенням однієї з шпальт із зазначенням порядку сортування чи ні такого вказівки. (За умовчанням рядки будуть сортироваться гаразд зростання значень у зазначеному столбце.).

Наприклад, видати перелік продуктів і змістом у яких основних речовин, у порядку спаду вміст білків | |Продукт|Белки |Жири |Углєв | |SELECT Продукт,| | | | | |Бєлки, Жири, | | | | | |Углєв | | | | | |FROM Продукти | | | | | |ORDER BY Бєлки | | | | | |DESC; | | | | | | |Судак |190. |80. |0. | | |Говядин|189. |124. |0. | | |а | | | | | |Сир |167. |90. |13. | | |Яйця |127. |115. |7. | | |Кава |127. |36. |9. | | |Борошно |106. |13. |732. |.

При включенні до списку ORDER BY кількох шпальт СУБД сортує рядки результату по значенням першого шпальти списку доки з’явиться кілька рядків з значеннями даних у тому стовпці. Такі рядки сортуються по значенням наступного шпальти зі списку ORDER BY і т.д.

Наприклад, видати вміст таблиці Страви, отсортировав її рядки по видам страв і основе:

| |Результат: | | | | |SELECT * |БЛ|Блюдо |В|Основа|Выход|Труд | |FROM Страви | | | | | | | |ORDER BY У | | | | | | | |Основа; | | | | | | | | |21|Пудинг рисовий |Г|Крупа |160. |6 | | |20|Каша рисова |Г|Крупа |210. |4 | | |18|Сырники |Г|Молоко|220. |4 | | |. | | | | | | | |. | | | | | | | |. | | | | | | | |16|Драчена |Г|Яйца |180. |4 | | |28|Крем сирний |Д|Молоко|160. |4 | | |. | | | | | | | |. | | | | | | | |. | | | | | | | |26|Яблоки печені |Д|Фрукты|160. |3 | | |7 |Сметана |З|Молоко|140. |1 | | |8 |Сир |З|Молоко|140. |2 | | |2 |Салат м’ясної |З|Мясо |200. |4 | | |6 |М'ясо з гарниром|З|Мясо |250. |3 | | |1 |Салат літній |З|Овощи |200. |3 | | |. | | | | | | | |. | | | | | | | |. | | | | | |.

З іншого боку, до списку ORDER BY можна включати як ім'я шпальти, а його порядкову позицію у переліку SELECT. Завдяки цьому можливо впорядкування результатів з урахуванням вычисляемых шпальт, які мають імен. Наприклад, запрос.

SELECT Продукт, ((Белки+Углев)*4.1+Жиры*9.3) FROM Продукти ORDER BY 2; дозволить отримати список продуктів, показаний на рис. 2.3,в — переупорядоченный зі збільшення значень калорійності список рис. 2.3,а.

Агрегирование данных.

SQL-функции.

У SQL існує низка спеціальних стандартних функцій (SQL-функций). Крім спеціального випадку COUNT (*) кожна з цих функцій оперує сукупністю значень шпальти деякою таблиці і це створює єдине значення, обумовлений так: COUNT 5. число значень в стовпці, SUM 6. сума значень в стовпці, AVG 7. середнє в стовпці, MAX 8. найбільше значення в стовпці, MIN 9. щонайменше значення в столбце.

Для функцій SUM і AVG аналізований стовпець мусить мати числові значения.

Слід зазначити, що саме стовпець — це стовпець віртуальної таблиці, в якої можуть утримуватися дані з шпальти базової таблиці, а й дані, отримані шляхом функціонального перетворення і (чи) зв’язування символами арифметичних операцій значень вже з чи навіть кількох шпальт. У цьому вираз, що б стовпець такий таблиці, може бути як завгодно складним, але з повинна утримувати SQL-функций (вкладеність SQL-функций заборонена). Проте з SQL-функций можна складати будь-які выражения.

Аргументу всіх функцій, крім COUNT (*), може передувати ключове слово DISTINCT (різний), указывающее, що надлишкові дублюючі значення були б неможливими до того, як застосовуватиметься функція. Спеціальна ж функція COUNT (*) служить для підрахунку всіх без винятку рядків таблиці (включаючи дубликаты).

Функції без використання фрази GROUP BY.

Не використовується фраза GROUP BY, то перелік элементов_SELECT можна включати лише SQL-функции чи висловлювання, містять таких функцій. Інакше кажучи, не можна мати у списку стовпчики, які є аргументами SQL-функций.

Наприклад, видати даних про масі цибулі (ПР=10), проданого постачальниками, і зазначити розмір цих поставщиков:

| |Резул| | | |ьтат:| | | | | | |SELECT SUM (К_во), COUNT (К_во) | | | | | | | |FROM Поставки | | | |WHERE ПР = 10; | | | | |SUM (К|COUNT (К_во) | | |_у) | | | |220 |2 |.

Якби висновку в результат що й номери продукту було сформовано запрос.

SELECT ПР, SUM (К_во), COUNT (К_во) FROM Поставки WHERE ПР = 10; було б отримано повідомлення про помилку. Це з тим, що SQL-функция створює єдине значення з багатьох значень столбца-аргумента, а для «вільного» шпальти має бути видано все безліч його значень. Без спеціального вказівки (воно задається фразою GROUP BY) SQL нічого очікувати з’ясовувати, однакові значення цього безлічі (як у нашому прикладі, де ПР=10) чи різні (як за відсутності WHERE фрази). Тож такий запит відхиляється системою. Щоправда, хто б забороняє дати запрос.

SELECT «У цибулі = «, SUM (К_во), COUNT (К_во) FROM Поставки WHERE ПР = 10; |Результат: | | | | «У цибулі = «|SUM (К_во) |COUNT (К_во) | |У цибулі = |220 |2 |.

Наголосимо також на, що у столбце-аргументе перед застосуванням будь-який функції, крім COUNT (*), виключаються все невизначені значення. Якщо виявляється, що аргумент — порожній безліч, функція COUNT приймає значення 0, інші ж — NULL.

Наприклад, щоб одержати суми цін, середньої ринкової ціни, кількості поставлених продуктів і кількість різних цін продуктів, проданих коопторгом ВРОЖАЙ (ПС=5), і навіть щоб одержати кількості продуктів, які можуть опинитися поставлятися цим коопторгом, можна надати запрос.

SELECT SUM (Цена), AVG (Цена), COUNT (Цена),.

COUNT (DISTINCT Цена), COUNT (*) FROM Поставки WHERE ПС = 5; і получить.

|SUM (Цена) |AVG (Цена) |COUNT (Цена) |COUNT (DISTINCT Ціна) |COUNT (*) | |6.2 |1.24 |5 |4 |7 |.

У другому прикладі, де треба дізнатися «Скільки поставлено моркви і скільки постачальників її поставляют?»:

SELECT SUM (К_во), COUNT (К_во) FROM Поставки WHER ПР = 2; отримають відповідь: |SUM (К_во) |COUNT (К_во) | |-0- |0 |.

Нарешті, спробуємо отримати суму маси поставленого цибулі з його середньої ціною («Чоботи з яєчнею»): | |Результат: | | | | |SELECT (SUM (К_во) | | |+AVG (Цена)) | | |FROM Поставки | | |WHERE ПР = 10; | | | |SUM (К_во)+AVG (Цена)| | |220.6 |.

Фраза GROUP BY.

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

SELECT ПР, SUM (К_во) FROM Поставки GROUP BY ПР; Результат показаний на рис. 2.5,а.

|а) | |б| | | |в) | |р) | | | |)| | | | | | | |ПР | |ПС |ПР |Ціна |К_во |ПР | |ПР | | |9 |0 |1 |9 |-0- |-0- |1 |370 |9 |0 | |11 |150 |3 |9 |-0- |-0- |2 |0 |11 |150 | |12 |30 |5 |9 |-0- |-0- |3 |250 |12 |30 | |15 |370 |1 |11 |1.50 |50 |4 |100 |15 |70 | |1 |370 |5 |11 |-0- |-0- |5 |170 |1 |370 | |3 |250 |6 |11 |-0- |-0- |6 |220 |3 |250 | |5 |170 |8 |11 |1.00 |100 |7 |200 |5 |70 | |6 |220 |1 |12 |3.00 |10 |8 |150 |6 |140 | |8 |150 |3 |12 |2.50 |20 |9 |0 |8 |150 | |7 |200 |6 |12 |-0- |-0- |10 |220 |7 |200 | |2 |0 |1 |15 |2.00 |170 |11 |150 |2 |0 | |4 |100 |3 |15 |1.50 |200 |12 |30 |4 |100 | |13 |190 |2 |1 |3.60 |300 |13 |190 |13 |190 | |14 |70 |7 |1 |4.20 |70 |14 |70 |14 |70 | |16 |250 |2 |3 |-0- |-0- |15 |370 |16 |250 | |17 |50 |7 |3 |4.00 |250 |16 |250 |17 |50 | |10 |220 |.. .| | | |17 |50 |10 |220 |.

Малюнок 2.5.

Фраза GROUP BY (групувати по) ініціює перекомпонування зазначеної у FROM таблиці за групами, кожна з яких має однакові значення стовпці, зазначеній у GROUP BY. У означеному прикладі рядки таблиці Поставки групуються отож у одному гуртові містяться все рядки для продукту з ПР = 1, на другий — для продукту з ПР = 2 тощо. (див. рис. 2.5,б). Далі до кожної групі застосовується фраза SELECT. Кожне вираження у цієї фрази повинні брати єдине значення для групи, тобто. воно може або значенням шпальти, вказаної у GROUP BY, або арифметичним вираженням, які мають це значення, або константою, або одній з SQL-функций, яка оперує усіма значеннями шпальти групи і зводить цих значень до єдиної значенням (наприклад, до сумме).

Зазначимо, що фраза GROUP BY передбачає ORDER BY. Щоб гарантувати впорядкування по ПР результату аналізованого прикладу (рис. 2.5,в) слід надати запрос.

SELECT ПР, SUM (К_во) FROM Поставки GROUP BY ПР ORDER BY ПР;

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

SELECT Т, БЛ, COUNT (БЛ) FROM Замовлення GROUP BY Т, БЛ; можна почути коди і кількість порцій страв, замовлених відпочиваючими пансіонату (32 людини) кожну з трапез наступного дня: |Т |БЛ |COUNT (БЛ) | |1 |3 |18 | |1 |6 |14 | |1 |19 |17 | |1 |21 |15 | |… | | |.

Використання фрази HAVING.

Фраза HAVING (рис. 2.3) відіграє таку ж роль для груп, як і фраза WHERE для рядків: вона використовується щоб уникнути груп, точно як і, як WHERE використовується щоб уникнути рядків. Цю фразу входить у пропозицію лише за наявності фрази GROUP BY, а вираження у HAVING повинні брати єдине значення для группы.

Наприклад, видати коди продуктів, поставлених більш як двома постачальниками: | |Результат: |ПР | |SELECT | | | |FROM Поставки | | | |GROUP BY ПС | | | |HAVING COUNT (*) 2;| | | | | |9 | | | |11 | | | |12 | | | | |.

2.2.3. Використання запитів із кількох таблицы.

Про засоби одночасної роботи з безліччю таблиц.

Чіпаючи питання проектування баз даних, ми з’ясували, що бази даних — це безліч взаємозалежних сутностей чи відносин (таблиць) в термінології реляционных СУБД. Під час проектування прагнуть створювати таблиці, у кожному у тому числі містилася б інформація про одне і лише про одному типі сутностей. Це полегшує модифікацію бази даних, і підтримку її цілісності. Але такий підхід важко засвоюється початківцями проектантами, які намагаються прив’язати проект до майбутнім додатків й дуже організувати таблиці, щоб у кожній їх зберігалося усе необхідне для реалізації можливих запитів. Типовий питання: чого ж отримати інформацію про тому, де купити продукти на приготування тієї чи іншої страви куштував і визначити її калорійність і вартість, якщо потрібні дані «розсипані» по семи різним таблицям? Чи не ліпше мати одну велику таблицю, що містить вся інформація бази даних ПАНСІОН ?

Навіть попри відсутність коштів одночасного доступу до багатьох таблицям небажаний проект, у якому інформацію про багатьох типах сутностей перемішана лише у таблиці. SQL ж має чудовим механізмом для одночасної чи послідовної обробки даних із кількох взаємозалежних таблиць. У ньому реалізовані можливості «з'єднувати» чи «об'єднувати» кілька таблиць так звані «вкладені подзапросы». Наприклад, щоб отримати перелік постачальників продуктів, необхідні приготування Сырников, може бути запрос.

SELECT Продукт, Ціна, Назва, Статус FROM Продукти, Склад, Страви, Поставки, Постачальники WHERE Продукты. ПР = Состав. ПР AND Состав. БЛ = Блюда. БЛ AND Поставки. ПР = Состав. ПР AND Поставки. ПС = Поставщики. ПС AND Страва = «Сирники «AND Ціна IS NOT NULL;

|Продукт |Ціна |Назва |Статус | |Яйця |1.8 |ПОРТОС |Кооператив | |Яйця |2. |КОРЮШКА |Кооператив | |Сметана |3.6 |ПОРТОС |Кооператив | |Сметана |2.2 |ОГІРОЧОК |Ферма | |Сир |1. |ОГІРОЧОК |Ферма | |Борошно |0.5 |ВРОЖАЙ |Коопторг | |Цукор |0.94 |ТУЛЬСЬКИЙ |Універсамам | |Цукор |1. |ВРОЖАЙ |Коопторг |.

Він отримано так: СУБД послідовно формує рядки декартова твори таблиць, перелічених у фразі FROM, перевіряє, задовольняють чи дані сформованої рядки умовам фрази WHERE, і якщо задовольняють, то включає у відповідь запит ті її поля, які перераховані у фразі SELECT.

Слід сказати, що у SELECT і WHERE (щоб уникнути двозначності) посилання все (*) чи окремі стовпчики можуть (котрий іноді повинні) уточнюватися ім'ям відповідної таблиці, наприклад, Поставки. ПС, Поставщики. ПС, Меню.*, Состав. БЛ, Страви.* і т.п.

Вочевидь, що з допомогою сполуки нескладно сформувати запит на обробку даних із кількох таблиць. З іншого боку, у такому запит можна включити будь-які частини пропозиції SELECT, розглянуті у розділі 2 (висловлювання з допомогою функцій, групування з відбором зазначених груп, і упорядкуванням отриманого результату). Отже, сполуки дозволяють обробляти безліч взаємозалежних таблиць як єдину таблицю, у якій перемішана інформацію про багатьох типах сутностей. Тому початкуючий проектант бази даних може спокійно створювати маленькі нормалізовані таблиці, оскільки вона завжди може мати простий їх будь-яку «велику» таблицу.

Крім механізму сполук, у SQL є механізм вкладених подзапросов, дозволяє об'єднати кілька простих запитів на єдиній пропозиції SELECT. Інакше кажучи, вкладений подзапрос — то це вже знайомий нам подзапрос (з невеликими огра-ничениями), який вкладено в WHERE фразу іншого вкладеного подзапроса чи WHERE фразу основного запроса.

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

SELECT Продукт, Ціна, Назва, Статус FROM Продукти, Склад, Страви, Поставки, Постачальники WHERE Продукты. ПР = Состав. ПР AND Состав. БЛ = Блюда. БЛ AND Поставки. ПР = Состав. ПР AND Поставки. ПС = Поставщики. ПС AND Страва = «Сирники «AND Ціна = (SELECT MIN (Цена).

FROM Поставки X.

WHERE X. ПР = Поставки. ПР); Результат запиту має вигляд |Продукт |Ціна |Назва |Статус | |Яйця |1.8 |ПОРТОС |Кооператив | |Цукор |0.94 |ТУЛЬСЬКИЙ |Універсамам | |Борошно |0.5 |ВРОЖАЙ |Коопторг | |Сметана |2.2 |ОГІРОЧОК |Ферма | |Сир |1. |ОГІРОЧОК |Ферма |.

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

Запити, використовують соединения.

Декартово твір таблиц.

Оскільки декартово твір n таблиць — це таблиця, яка містить все можливі рядки r, такі, що r є зчепленням будь-якої рядки першої таблиці, рядки другий таблиці, … і рядки енну кількість таблиці (чому ми вже навчилися виділяти з допомогою SELECT будь-яке підмножина реляційної таблиці), то залишилася тільки з’ясувати, чи можна з допомогою SELECT отримати декартово твір. Для отримання декартова твори кількох таблиць слід зазначити у фразі FROM перелік перемножаемых таблиць, тоді як у фразі SELECT — всі ці столбцы.

Так, щоб одержати декартова твори Вид_блюд і Трапези треба видати запрос.

SELECT Вид_блюд.*, Трапези.* FROM Вид_блюд, Трапези; Одержимо таблицю, що містить 5×3 = 15 строк:

|В |Вигляд |Т |Трапеза | |З |Закуска |1 |Сніданок | |З |Закуска |2 |Обід | |З |Закуска |3 |Вечеря | |З |Суп |1 |Сніданок | |З |Суп |2 |Обід | |З |Суп |3 |Вечеря | |Р |Гаряче |1 |Сніданок | |Р |Гаряче |2 |Обід | |Р |Гаряче |3 |Вечеря | |Д |Десерт |1 |Сніданок | |Д |Десерт |2 |Обід | |Д |Десерт |3 |Вечеря | |М |Напій |1 |Сніданок | |М |Напій |2 |Обід | |М |Напій |3 |Вечеря |.

У другому прикладі, де перемножуються таблиці Меню, Трапези, Вид_блюд, Блюда:

SELECT Меню.*, Трапези.*, Вид_блюд.*, Страви.* FROM Меню, Трапези, Вид_блюд, Страви; утворюється таблиця (рис 2.6), яка містить 21×3×5×33 = 10 395 строк.

Эквисоединение таблиц.

Якщо з декартова твори прибрати непотрібні рядки — і стовпчики, то можна було одержати актуальні таблиці, відповідні будь-якій з соединений.

|Меню| | |Трап| |Вигляд_| |Страв| | | | | | | | | |езы | |страв| |а | | | | | | |Т |У |БЛ |Т |Трап|В |Вигляд |БЛ |Блюд|В |Осно|Выхо|Труд| | | | | |еза | | | |про | |ва |буд | | |1 |З |3 |1 |Завт|З |Заку|1 |Сала|З |Овощ|200.|3 | | | | | |рак | |ска | |т | |і | | | | | | | | | | | |летн| | | | | | | | | | | | | |ий | | | | | |1 |З |3 |1 |Завт|З |Заку|2 |Сала|З |Мясо|200.|4 | | | | | |рак | |ска | |т | | | | | | | | | | | | | |мясн| | | | | | | | | | | | | |ой | | | | | |1 |З |3 |1 |Завт|З |Заку|3 |Сала|З |Овощ|200.|4 * | | | | | |рак | |ска | |т | |і | | | | | | | | | | | |віта| | | | | | | | | | | | | |минн| | | | | | | | | | | | | |ый | | | | | |.. | | | | | | | | | | | | | |. | | | | | | | | | | | | | |1 |З |3 |1 |Завт|З |Заку|12 |Суп |З |Моло|500.|3 | | | | | |рак | |ска | |моло| |до | | | | | | | | | | | |чный| | | | | |1 |З |3 |1 |Завт|З |Заку|13 |Баст|Г |Мясо|300.|5 | | | | | |рак | |ска | |урма| | | | | |.. | | | | | | | | | | | | | |. | | | | | | | | | | | | | |1 |З |3 |1 |Завт|З |Заку|32 |Кофе|Н |Кофе|100.|1 | | | | | |рак | |ска | |черн| | | | | | | | | | | | | |ый | | | | | |1 |З |3 |1 |Завт|З |Заку|33 |Кофе|Н |Кофе|200.|2 | | | | | |рак | |ска | |на | | | | | | | | | | | | | |моло| | | | | | | | | | | | | |ке | | | | | |1 |З |6 |1 |Завт|З |Заку|1 |Сала|З |Овощ|200.|3 | | | | | |рак | |ска | |т | |і | | | | | | | | | | | |летн| | | | | | | | | | | | | |ий | | | | | |1 |З |6 |1 |Завт|З |Заку|2 |Сала|З |Мясо|200.|4 | | | | | |рак | |ска | |т | | | | | | | | | | | | | |мясн| | | | | | | | | | | | | |ой | | | | | |1 |З |6 |1 |Завт|З |Заку|3 |Сала|З |Овощ|200.|4 | | | | | |рак | |ска | |т | |і | | | | | | | | | | | |віта| | | | | | | | | | | | | |минн| | | | | | | | | | | | | |ый | | | | | |1 |З |6 |1 |Завт|З |Заку|4 |Сала|З |Рыба|200.|4 | | | | | |рак | |ска | |т | | | | | | | | | | | | | |рыбн| | | | | | | | | | | | | |ый | | | | | |1 |З |6 |1 |Завт|З |Заку|5 |Пашт|З |Рыба|120.|5 | | | | | |рак | |ска | |ет | | | | | | | | | | | | | |з | | | | | | | | | | | | | |риби| | | | | |1 |З |6 |1 |Завт|З |Заку|6 |Мясо|З |Мясо|250.|3 * | | | | | |рак | |ска | |з | | | | | | | | | | | | | |гарн| | | | | | | | | | | | | |іром| | | | | |.. | | | | | | | | | | | | | |. | | | | | | | | | | | | |.

Малюнок 2.6.

Вочевидь, що актуальних рядків забезпечується введенням в запит WHERE фрази, якою встановлено відповідність між: кодами трапез (Т) в таблицях Меню і Трапези (Меню.Т = Трапезы. Т), кодами видів страв (У) в таблицях Меню і Вид_блюд (Меню.В = Вид_блюд.В), номерами страв (БЛ) в таблицях Меню і Страви (Меню.БЛ = Блюда. БЛ). Такий скоригований запрос.

SELECT Меню.*, Трапези.*, Вид_блюд.*, Страви.* FROM Меню, Трапези, Вид_блюд, Страви WHERE Меню. Т = Трапезы. Т AND Меню. В = Вид_блюд.В AND Меню. БЛ = Блюда. БЛ; дозволить отримати эквисоединение таблиць Меню, Трапези, Вид_блюд і Страви: |Т |У |БЛ |Т |Трап|В |Вигляд |БЛ |Блюд|В |Осно|Выхо|Труд| | | | | |еза | | | |про | |ва |буд | | |1 |З |3 |1 |Завт|З |Заку|3 |Сала|З |Овощ|200.|4 | | | | | |рак | |ска | |т | |і | | | | | | | | | | | |віта| | | | | | | | | | | | | |минн| | | | | | | | | | | | | |ый | | | | | |1 |З |6 |1 |Завт|З |Заку|6 |Мясо|З |Мясо|250.|3 | | | | | |рак | |ска | |з | | | | | | | | | | | | | |гарн| | | | | | | | | | | | | |іром| | | | | |1 |Р |19 |1 |Завт|Г |Горя|19 |Омле|Г |Яйца|200.|5 | | | | | |рак | |чее | |т з | | | | | | | | | | | | | |луко| | | | | | | | | | | | | |м | | | | | |.. | | | | | | | | | | | | | |. | | | | | | | | | | | | | |3 |Р |16 |3 |Ужин|Г |Горя|16 |Драч|Г |Яйца|180.|4 | | | | | | | |чее | |ена | | | | | |3 |М |30 |3 |Ужин|Н |Напи|30 |Комп|Н |Фрук|200.|2 | | | | | | | |струм | |від | |ти | | | |3 |М |31 |3 |Ужин|Н |Напи|31 |Моло|Н |Моло|200.|2 | | | | | | | |струм | |чный| |до | | | | | | | | | | | |напи| | | | | | | | | | | | | |струм | | | | |.

Природний з'єднання таблиц.

Легко помітити, що у эквисоединение таблиць ввійшли дублікати шпальт, якими проводилося з'єднання (Т, У і БЛ). Щоб не допустити цих дублікатів можна створити природне з'єднання тієї ж таблиц:

SELECT Т, У, БЛ, Трапеза, Вигляд, Страва, Основа, Вихід, Праця FROM Меню, Трапези, Вид_блюд, Страви WHERE Меню. Т = Трапезы. Т AND Меню. В = Вид_блюд.В AND Меню. БЛ = Блюда. БЛ; Реалізація природного сполуки таблиць має вид.

|Т |У |БЛ |Трапез|Вид |Страва |Основа|Выход |Праця | | | | |а | | | | | | |1 |З |3 |Завтра|Закуск|Салат |Овочі |200. |4 | | | | |до |а |витами| | | | | | | | | |нный | | | | |1 |З |6 |Завтра|Закуск|Мясо с|Мясо |250. |3 | | | | |до |а |гарнір| | | | | | | | | |ом | | | | |1 |Р |19 |Завтра|Горяче|Омлет |Яйця |200. |5 | | | | |до |е |з | | | | | | | | | |цибулею | | | | |… | | | | | | | | | |3 |Р |16 |Вечеря |Горяче|Драчен|Яйца |180. |4 | | | | | |е |а | | | | |3 |М |30 |Вечеря |Напито|Компот|Фрукты|200. |2 | | | | | |до | | | | | |3 |М |31 |Вечеря |Напито|Молочн|Молоко|200. |2 | | | | | |до |ый | | | | | | | | | |напито| | | | | | | | | |до | | | |.

Композиція таблиц.

Щоб не допустити всіх шпальт, якими проводиться з'єднання таблиць, треба створити композицию.

SELECT Трапеза, Вигляд, Страва, Основа, Вихід, Праця FROM Меню, Трапези, Вид_блюд, Страви WHERE Меню. Т = Трапезы. Т AND Меню. В = Вид_блюд.В AND Меню. БЛ = Блюда. БЛ; має вид |Трапеза |Страва |Вигляд |Основа |Вихід |Праця | |Сніданок |Салат вітамінний |Закуска |Овочі |200. |4 | |Сніданок |М'ясо з гарніром |Закуска |М'ясо |250. |3 | |Сніданок |Омлет з цибулею |Гаряче |Яйця |200. |5 | |... | | | | | | |Вечеря |Драчена |Гаряче |Яйця |180. |4 | |Вечеря |Компот |Напій |Фрукти |200. |2 | |Вечеря |Молочний напій |Напій |Молоко |200. |2 |.

Тета-соединение таблиц.

У базі даних ПАНСІОН важко підібрати нескладний приклад, який ілюструє тета-соединение таблиць. Тому сконструюємо такий надуманий запрос:

SELECT Вид_блюд.*, Трапези.* FROM Вид_блюд, Трапези WHERE Вигляд Трапеза; дозволяє вибрати з отриманого декартова твори таблиць Вид_блюд і Трапези лише ті рядки, у яких значення трапези «менше» (за алфавітом) значення виду страви: |У |Вигляд |Т |Трапеза | |З |Закуска |1 |Сніданок | |З |Суп |1 |Сніданок | |З |Суп |2 |Обід | |М |Напій |1 |Сніданок |.

Поєднання таблиць з додатковим условием.

При формуванні сполуки створюється робоча таблиця, до котрої я застосовні усі фінансові операції: відбір потрібних рядків сполуки (WHERE фраза), впорядкування одержуваного результату (ORDER BY фраза) і агрегатування даних (SQL-функции і GROUP BY фраза).

Наприклад, щоб одержати переліку страв, запропонованих у меню на сніданок, можна сформувати запит з урахуванням композиции:

SELECT Вигляд, Страва, Основа, Вихід, «Номер — «, БЛ FROM Меню, Трапези, Вид_блюд, Страви WHERE Меню. Т = Трапезы. Т AND Меню. В = Вид_блюд.В AND Меню. БЛ = Блюда. БЛ AND Трапеза = 'Завтрак';

|Вид |Страва |Основа |Выхо| «Номе|БЛ | | | | |буд |р — «| | |Закуск|Салат |Овочі |200.|Номер|3 | |а |витаминны| | |- | | | |і | | | | | |Закуск|Мясо з |М'ясо |250.|Номер|6 | |а |гарніром | | |- | | |Горяче|Омлет з |Яйця |200.|Номер|19 | |е |цибулею | | |- | | |Горяче|Пудинг |Крупа |160.|Номер|21 | |е |рисовий | | |- | | |Напито|Молочный |Молоко |200.|Номер|31 | |до |напій | | |- | | |Напито|Кофе |Кава |100.|Номер|32 | |до |чорний | | |- | |.

Поєднання таблиці зі своїми копией.

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

Наприклад, під час створення списків студентів (таблиця Студенти) може бути повторний введення даних якесь студента з наданням йому другого номери залікової книжки. Для виявлення таких помилок можна з'єднати таблицю Студенти з її тимчасової копією, встановивши в WHERE фразі рівність значень всіх однойменних шпальт цих таблиць крім шпальт з номером залікової книжки (для останніх треба встановити умова нерівності значений).

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

FROM Страви X, Страви Y, Страви Z сформувати три копії таблиці Страви із конкретними іменами X, Y і Z.

Як приклад сполуки таблиці із нею самої сформуємо запит на висновок таких пар страв таблиці Страви, у яких збігається основа, а назва першого страви пари менше (за алфавітом), ніж номер другої тарелі пари. Для цього можна створити запит з одного копією таблиці Страви (Копия):

SELECT Страва, Копия. Блюдо, Основа FROM Страви, Страви Копія WHERE Основа = Копия. Основа AND Страва < Копия. Блюдо; чи двома її копіями (Перша й Вторая):

SELECT Первая. Блюдо, Вторая. Блюдо, Основа FROM Страви Перша, Страви Друга WHERE Первая. Основа = Вторая. Основа AND Первая. Блюдо < Вторая. Блюдо; Одержимо результат вида.

|Первая.Блюдо |Вторая.Блюдо |Основа | |Морква з рисом |Помідори з цибулею |Овочі | |Морква з рисом |Салат літній |Овочі | |Морква з рисом |Салат вітамінний |Овочі | |Помідори з цибулею |Салат вітамінний |Овочі | |Помідори з цибулею |Салат літній |Овочі | |Салат вітамінний |Салат літній |Овочі | |Бастурма |Бефстроганов |М'ясо | |Бастурма |М'ясо з гарніром |М'ясо | |Бефстроганов |М'ясо з гарніром |М'ясо |.

Вкладені подзапросы.

Види вкладених подзапросов.

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

Існують прості і коррелированные вкладені подзапросы. Вони входять у WHERE (HAVING) фразу з допомогою умов IN, EXISTS чи одного з умов порівняння (= | < | < |.