1 Введення в Реляційні Бази Даних
2 SQL: Короткий Огляд
3 Використання SQL Для Витяги Інформації з Таблиць
4 Використання Реляційних і булевих Операторів при Створенні більш Складних предикатів
5 Використання Спеціальних Операторів в Умовах
6 Узагальнення Даних за допомогою агрегатних функцій
7 Форматування Висновку Запиту
8 Запит Багатьох Таблиць Як Однією
9 Об'єднання Таблиці з Собою
10 Приміщення Одного Запиту Всередину Іншого
11 співвіднесення Підзапити
12 Використання Оператора EXISTS
13 Використання Операторів ANY, ALL, і SOME
14 Використання Пропозиції UNION
15 Введення, Видалення, і Зміна Значення Поля
16 Використання підзапитів з Командами Модифікації
17 Створення таблиць
18 Обмеження Значний Ваших Даних
19 Підтримка Цілісності Ваших Даних
20 Введення: Уявлення
21 Зміна Значний з Допомогою уявлень
22 Визначення Хто Що Може Робити
23 Глобальні Аспекти SQL
24 Як Дані SQL сожержат у впорядкованому вигляді
25 Використання SQL з Іншими Мовами (Вкладений SQL)
A Відповіді для Вправ
B Типи SQL Даних
C Деякі Загальні Нестандартні Особливості SQL
D Синтаксис і Команди Посилання
E Таблиці Використовувані в прикладах
1. Введення в реляційну базу даних
SQL (ЗВИЧАЙНО їх вимовляють ЯК "SEEQUEL") символізує собою Структурований Мова Запитів. Це - мова який дає вам можливість створювати і працювати в реляційних базах даних, які є наборами зв'язаної інформації що зберігається в таблицях.
Світ баз даних стає все більш і більш єдиним, що призвело до необхідності створення стандартної мови який міг би використовуватися щоб функціонувати у великій кількості різних видів комп'ютерних середовищ. Стандартна мова дозволить користувачам, що знають один набір команд, використовувати їх щоб створювати, відшукувати, змінювати, і передавати інформацію незалежно від того чи працюють вони на персональному комп'ютері, мережевій робочій станції, або на універсальній ЕОМ. У нашому все більш і більш взаємопов'язаному комп'ютерному світі, користувач постачання такою мовою, має величезну перевагу у використанні та узагальненні інформації з ряду джерел за допомогою безлічі способів.
Елегантність і незалежність від специфіки комп'ютерних технологій, а також його підтримка лідерами промисловості в області технології реляційних баз даних, зробило SQL, і ймовірно протягом осяжного майбутнього залишить його, основним стандартною мовою. З цієї причини, будь-хто хоче працювати з базами даних 90-х років повинен знати SQL.
Стандарт SQL визначається ANSI (Американським Національним Інститутом Стандартів) і в даний час також приймається ISO (МІЖНАРОДНОЇ ОРГАНІЗАЦІЄЮ ПО СТАНДАРТИЗАЦІЇ). Однак, більшість комерційних програм баз даних розширюють SQL без повідомлення ANSI, додаючи різні інші особливості в цю мову, які, як вони вважають, будуть вельми корисні. Іноді вони дещо порушують стандарт мови, хоча хороші ідеї мають тенденцію розвиватися і незабаром ставати стандартами "ринку" самі по собі в силу корисності своїх якостей. У цій книзі, ми будемо, в основному, слідувати стандарту ANSI, але одночасно іноді показуватиме і деякі найбільш загальні відхилення від його стандарту.
Що таке - реляційна бази даних?
Gerry Farish (415) 365-8775 127 Primrose Ave., SF
Celia Brock (707) 874-3553 246 # 3rd St., Sonoma
Yves Grillet (762) 976-3665 778 Modernas, Barcelona
Те що ви отримали є основою реляційної бази даних як і було визначено на початку цього обговорення - а саме, двовимірною (рядок і стовпець) таблицею інформації. Однак, реляційні бази даних рідко складаються з однієї таблиці. Така таблиця менше ніж файлова система. Створивши кілька таблиць взаємозалежної інформації, ви зможете виконати більш складні і потужні операції з вашими даними. Потужність бази даних залежить від зв'язку яку ви можете створити між фрагментами інформації, а не від самого фрагмента інформації.
Зв'язування однієї таблиці з іншого
Пацієнт Доктор Страховка Баланс
Farish Drume B.C./B.S. $ 272.99
Grillet Halben None $ 44. 76
Brock Halben Health, Inc. $ 9077.47
Багато потужних функцій можна виконати витягуючи інформацію з цих
таблиць згідно із зазначеними параметрами, особливо коли ці параметри
включають в себе фрагменти інформації свзанние в різних таблицях
один з одним. Наприклад, візьмемо - докторів. Припустимо доктор Halben
пацієнтів - його. Хоча, в цьому простому прикладі, він міг би тримати це в
ці таблиці можуть бути дуже великими і дуже складними. програми
реляційної бази даних розроблялися для того щоб обробляти
великі і складні сукупності даних такого типу, що очевидно є-
ється більш універсальним методом в діловому світі. Навіть якби база
даних лікарні містила сотні або тисячі імен - як це ймовірно і
буває на практиці - одна команда SQL могла б видати докторові Halben
інформацію в якій він потребував майже негайно.
Порядок рядків довільний
Щоб підтримувати максимальну гнучкість, рядки таблиці, по визна
лению, не повинні знаходитися ні в якому певному порядку. З цією
порядку. У системах з реляційною базою даних, є одна потужна
можливість для пользоватей - це здатність упорядковувати інформацію
так щоб вони могли відновлювати її.
Розглянемо другу таблицю. Іноді Вам необхідно бачити цю інформа-
цію впорядкованої в алфавітному порядку за іменами, іноді в возрастаю-
щем або спадному порядку, а іноді згрупованої по відношенню до ка-
кому-небудь лікаря. Накладення порядку набору в рядках буде сталкі-
тися зі здатністю замовника змінювати його, тому рядки завжди
розглядаються як невпорядковані. З цієї причини, ви не можете
просто сказати: "Ми хочемо подивитися п'ятий рядок таблиці." Пренебре-
гаю порядком в якому дані вводилися або будь-яким іншим критерієм, ми
визначимо, не ту рядок, хоча вона і буде п'ятою. Рядки таблиці кото
риє розглядаються, не будуть у будь-якої певної послідовності
Ідентифікація рядків (Ппервічние ключі)
З цих та інших причин, ви повинні мати стовпець у вашій таблиці
який би унікально ідентифікував кожен рядок. Зазвичай, цей стіл-
Бец містить номер - наприклад, номер пацієнта призначається кожному па-
ціент. Звичайно, ви могли б використовувати ім'я пацієнтів, але можливо
що є кілька Mary Smiths; і в цьому випадку, ви не будете мати
іншого способу щоб відрізнити цих пацієнтів один від одного.
Ось чому номера так необхідні. Такий унікальний стовпець (або уні
Кальна група стовпців), використовуваний щоб ідентифікувати кожну
рядок і зберігання всі рядки окремо, називаються - первинними ключа-
Первинні ключі таблиці важливий елемент в структурі бази даних. вони
- основа вашої системи запису в файл; і коли ви хочете знайти визна
ленну рядок в таблиці, ви посилаєтеся до цього первинному ключу. Крім
того, первинні ключі гарантують, що ваші дані мають певну
цілісність. Якщо первинний ключ правильно використовується і підтримуючи
ється, ви будете знати що немає порожніх рядків таблиці і що кожен рядок
відрізняється від будь-якої іншої рядка. Ми будемо обговорювати ключі і далі
коли поговоримо щодо довідкової цілісності в Главі 19.
Стовпці позначаються і нумеруються
На відміну від рядків, стовпці таблиці (також звані полями) упоря-
це означає що кожен стовпець даної таблиці повинен мати унікальне
ім'я щоб уникнути неоднозначності. Найкраще якщо ці імена укази-
використовувати такі скорочення для імені стовпця, як cname для імені за-
казчіка, і odate для дати порядку. Ми також дамо кожній таблиці лич-
ний числовий номер стовпця як первинний ключ. Наступного разу-
справ буде пояснювати ці таблиці і їх ключі детальніше.
Типова база даних
Таблиці 1.1, 1.2, і 1.3 складають реляційну базу даних яка
є мінімально достатньою щоб легко її відстежувати, і достатньо
точно повної, щоб ілюструвати головні поняття і практику викорис
Ці таблиці надруковані в цьому розділі а також в Додатку E. Так як
вони будуть використовуватися для ілюстрування різних особливостей
зручності посилання до них.
Ви могли вже звернути увагу що перший стовпець кожної таблиці з-
тримає номера чиї значення різні для кожного рядка. Як ви напевно
і припустили, це - первинні ключі таблиць. Деякі з цих номе-
рів також показані в стовпцях інших таблиць. В цьому немає нічого невер-
ного. Вони поазивают зв'язок між рядками які використовують значення
прийняте з первинного ключа, і рядками де це значення использу-
ється в самому первинному ключі.
Таблиця 1.1: Продавці
SNUM SNAME CITY COMM
+1001 Peel London .12
1002 Serres San Jose .13
1004 Motika London .11
1007 Rifkin Barcelona .15