Реляційні бази даних 3

Глава 1. реляційної бази даних. ВСТУП.

SQL (вимовляється як правило "СЕКВЕЛ" (або, більш англообразно - СКЬЮЕЛ)) означає Структурований Мова Запитів.

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

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

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

Елегантність і незалежність від специфіки комп'ютерних технологій, а також його підтримка лідерами промисловості в області технології РБД, зробили SQL (і, ймовірно, протягом осяжного майбутнього, залишать його) основним стандартною мовою БД. З цієї причини будь-який, хто хоче працювати з базами даних 90-х років (минулого століття), повинен знати SQL.

Стандарт SQL визначається ANSI (Американським Національним Інститутом Стандартів) і в даний час також приймається ISO (Міжнародною організацією зі стандартизації). Однак більшість комерційних програм БД розширюють SQL без повідомлення ANSI. додаючи різні особливості в цю мову, які, як вони вважають, будуть вельми корисні.
Іноді це кілька порушує стандарт мови, хоча хороші ідеї мають тенденцію розвиватися і ставати стандартами ринку в силу корисності своїх якостей.

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

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

ПЕРЕД ТИМ ЯК ВИ ЗМОЖЕТЕ ВИКОРИСТОВУВАТИ SQL, ви повинні зрозуміти, що таке реляційні бази даних.

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

Однак РБД рідко складаються з однієї таблиці. Така таблиця менше, ніж файлова система. Створивши кілька таблиць взаємозалежної інформації, ви зможете виконувати більш складні і потужні операції з вашими даними. Потужність БД залежить від зв'язку, яку ви можете створити між фрагментами інформації, а не від самого фрагмента інформації.

Програми РБД розроблялися для того, щоб обробляти великі і складні сукупності даних такого типу, що, очевидно, є більш універсальним методом в діловому світі. Навіть якби БД лікарні містила сотні або тисячі імен, як це ймовірно і буває на практиці, одна команда SQL могла б видати докторові Halben інформацію, в якій він потребує, майже негайно.

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

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

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

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

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

Таблиці 1.1, 1.2 і 1.3 складають реляційну базу даних, яка є мінімально достатньою, щоб легко її відстежувати, і досить повної, щоб ілюструвати головні поняття і практику використання SQL. Ці таблиці надруковані в цьому розділі, а також в Додатку E.

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

Наприклад, поле snum в таблиці Замовників вказує, якому продавцеві призначений даний замовник. Номер поля snum пов'язаний з таблицею Продавців, яка дає інформацію про ці продавців. Очевидно, що продавець, якому призначено замовники, повинен вже існувати - тобто значення snum з таблиці Замовників повинне також бути представлено в таблиці Продавців. Якщо це так, то кажуть, що "система знаходиться в стані довідкової цілісності". Цей висновок буде більш повно і формально пояснений в Главі 19.

ПРИМІТКА: ці три представлених таблиці в тексті мають російськомовні імена - Продавці, Замовники і Замовлення - і далі будуть згадуватися саме під цими іменами. Імена будь-яких інших застосовуваних у книзі таблиць будуть написані по-англійськи, щоб відрізняти їх від базових таблиць цієї БД. Крім того, з метою однозначності імена замовників, продавців, Системних Каталогів, а також полів в тексті, також будуть дані на латині.

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

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

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

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

Тепер ви готові до занурення в SQL. Наступна глава дасть короткий розгляд мови та інформацію, яка допоможе вам звертатися до вже пройдених місцях.