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

Що таке бази даних?
У самому загальному сенсі база даних - це набір записів і файлів, організованих
спеціальним чином. У комп'ютері, наприклад, можна зберігати прізвища та адреси
друзів або клієнтів. Один з типів баз даних - це документи, набрані з
допомогою текстових редакторів і згруповані за темами. Інший тип - файли
електронних таблиць, що об'єднуються в групи по характеру їх використання.
Перші моделі даних
Зі зростанням популярності СУБД в 70-80-х роках з'явилося безліч різних моделей
даних. У кожної з них були свої переваги і недоліки, які зіграли
ключову роль у розвитку реляційної моделі даних, що з'явилася в чому
завдяки прагненню спростити і впорядкувати перші моделі даних.
Системи управління файлами.
До появи СКБД всі дані, які містилися у комп'ютерній системі
постійно, зберігалися у вигляді окремих файлів. Система управління файлами,
що звичайно є частиною операційної системи комп'ютера, стежила за
іменами файлів і місцями їх розташування. У системах управління файлами моделі
даних, як правило, не використовувалися; ці системи нічого не знали про внутрішнє
вмісту. Для такої системи файл, що містить документ текстового
процесора, нічим не відрізняється від файлу, що містить дані про нараховану
зарплати.
Знання про вміст файлу - які дані в ньому зберігаються і яка їхня структура -
було долею прикладних програм, що використовують цей файл, що ілюструє рис.
1.1.

У додатку для нарахування зарплати кожна з програм, що обробляють файл із
інформацією про службовців, містить у собі опис структури даних (ОСД),
що зберігаються в цьому файлі. Коли структура даних змінювалася - наприклад, у випадку
додавання нового елемента даних для кожного службовця, - необхідно було
модифіковані кожну з програм, які зверталися до файлу. З часом кількість
файлів і програм росло, і на супровід існуючих додатків доводилося
витрачати все більше і більше зусиль, що уповільнювало розробку нових
додатків.
Проблеми супроводження великих систем, заснованих на файлах, привели в кінці
60-х років до появи СУБД. В основі СУБД лежала проста ідея: вилучити з
програм визначення структури вмісту файлу і зберігати її разом з даними в
базі даних.
Ієрархічні СУБД
Однією з найбільш важливих сфер застосування перших СУБД було планування
виробництва для компаній, що займаються випуском продукції. Наприклад, якщо
автомобільна компанія хотіла випустити 10000 машин однієї моделі і 5000 машин
іншої моделі, їй необхідно було знати, скільки деталей слід замовити у
своїх постачальників. Щоб відповісти на це питання, необхідно визначити, з
яких деталей складаються ці частини і т.д. Наприклад, машина складається з двигуна,
корпусу і ходової частини; двигун складається з клапанів, циліндрів, свічок і т.д.
Робота зі списками складових частин була наче спеціально призначена для
комп'ютерів.
Список складових частин виробу за своєю природою є ієрархічної
структурою. Для зберігання даних, що мають таку структуру, була розроблена
ієрархічна модель даних, яку ілюструє рис. 1.2.

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

знайти конкретну деталь (праві двері) по її номеру;

перейти "вниз" до першого нащадку (ручка дверей);

перейти "вгору" до предка (корпус);

перейти "в сторону" до іншого нащадку (права двері).

Таким чином, для читання даних з ієрархічної бази даних потрібно
переміщуватися по записах, за один раз переходячи на одну запис вгору, вниз або в
сторону.
Однією з найбільш популярних ієрархічних СУБД була Information Management
System (IMS) компанії IBM, що з'явилася в 1968 році. Нижче перераховані
переваги IMS і реалізованої в ній ієрархічної моделі.

Простота моделі. Принцип побудови IMS був легкий для розуміння. Ієрархія бази
даних нагадувала структуру компанії або генеалогічне дерево.

Використання відносин предок/нащадок. СУБД IMS дозволяла легко представляти
відносини предок/нащадок, наприклад: "А є частиною В" або "А володіє В".

Швидкодія. У СУБД IMS відносини предок/нащадок були реалізовані у вигляді
фізичних покажчиків з одного запису на іншу, внаслідок чого переміщення
по базі даних відбувалося швидко. Оскільки структура даних у цій СУБД
відрізнялася простотою, IMS могла розміщувати запису предків і нащадків на диску
поруч один з одним, що дозволяло звести до мінімуму кількість операцій
запису-читання.

СУБД IMS все ще є однією з найбільш поширених СУБД для великих
ЕОМ компанії IBM. Частка мейнфреймів цієї компанії, на яких використовується дана
СУБД, перевищує 25%.
Мережні бази даних

Якщо структура даних виявлялася складніше, ніж звичайна ієрархія, простота
ієрархічної структури бази даних ставала її недоліком. Наприклад, в базі
даних для зберігання замовлень одне замовлення міг брати участь у трьох різних
відносинах предок/нащадок, що зв'язують замовлення з клієнтом, що розмістили його, з
службовцям, які прийняли його, і із замовленим товаром, що ілюструє рис. 1.3.
Такі структури даних не відповідали суворої ієрархії IMS.
У зв'язку з цим для таких додатків, як обробка замовлень, була розроблена
мережева модель даних. Вона була поліпшеного ієрархічною моделлю, в
якої один запис могла брати участь в декількох відносинах предок/нащадок,
як показано на рис. 1.4.

У мережевій моделі такі стосунки називалися множинами. У 1971 році на
конференції з мов систем даних був опублікований офіційний стандарт мережевих
баз даних, який відомий як модель CODASYL. Компанія IBM не стала
розробляти власну мережеву СУБД і замість цього продовжувала нарощувати
можливість IMS. Але в 70-х роках незалежні виробники програмного
забезпечення реалізували мережеву модель в таких продуктах, як IDMS компанії
Cullinet, Total компанії Cincom і СУБД Adabas, які придбали велику
популярність.
Мережні бази даних мали низку переваг:

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

Стандартизація. Поява стандарту CODASYL популярність мережевої моделі, а
такі постачальники міні-комп'ютерів, як Digital Equipment Corporation і Data
General, реалізували мережеві СУБД.

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

Звичайно, у мережевих баз даних були недоліки. Як і ієрархічні бази даних,
мережеві базі даних були дуже жорсткими. Набори відносин і структуру записів
доводилося ставити наперед. Зміна структури бази даних звичайно означало
перебудову всієї бази даних.
Як ієрархічна, так і мережна база даних були інструментами програмістів.
Щоб отримати відповідь на питання типу "Який товар найбільш часто замовляє
компанія Acme Manufacturing? ", програмісту доводилося писати програму для
навігації по базі даних. Реалізація призначених для користувача запитів часто
затягувалася на тижні і місяці, і до моменту появи програми інформація,
яку вона надавала, часто виявлялася марною.
Реляційна модель даних
Недоліки ієрархічної і мережної моделей призвели до появи нової,
реляційної моделі даних, створеної Коддом в 1970 року і викликала загальний
інтерес. Реляційна модель була спробою спростити структуру бази даних. У ній
були відсутні явні покажчики на предків і нащадків, а всі дані були
представлені у вигляді простих таблиць, розбитих на рядки і стовпці. На рис. 1.5.
показана реляційна версія мережевої бази даних, що містить інформацію про замовлення
і наведеної на рис. 1.4.

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


У відповідь на неправильне використання терміну "Реляційний" Коддом в 1985 році
написав статтю, де сформулював 12 правил, яким повинна задовольняти будь-яка
база даних, що претендує на звання реляційної. З тих пір дванадцять правил
Кодда вважаються визначенням реляційної СУБД. Однак можна сформулювати і
більш просте визначення:
Реляційної називається база даних, в якій всі дані, доступні
користувачеві, організовані у вигляді таблиць, а всі операції над даними зводяться до
операціями над цими таблицями.
Наведене визначення не залишає місця вбудованим вказівниками, наявними в
ієрархічних та мережевих СУБД. Незважаючи на це, реляційна СУБД також здатна
реалізувати відносини предок/нащадок, проте ці відносини представлені
виключно значеннями даних, що містяться в таблицях.
Таблиці
У реляційної бази даних інформація організована у вигляді таблиць, розділених на
рядки і стовпці, на перетині яких містяться значення даних. У кожної
таблиці є унікальне ім'я, що описує її вміст. Більш наочно
структуру таблиці ілюструє рис 1.6., на якому зображена таблиця OFFICES.

Кожна горизонтальний рядок цієї таблиці представляє окрему фізичну
сутність - один офіс. П'ять рядків таблиці разом представляють всі п'ять офісів
компанії. Всі дані, що містяться в конкретній рядку таблиці, відносяться до
офісу, який описується цим рядком.
Кожен вертикальний стовпець таблиці OFFICES представляє один елемент даних для
кожного з офісів. Наприклад, у стовпці CITY містяться назви міст, в
яких розташовані офіси. У стовпці SALES містяться обсяги продажів,
забезпечувані офісами.
На перетині кожного рядка з кожним стовпцем таблиці міститься в точності
одне значення даних. Наприклад, в рядку, що представляє нью-йоркський офіс, в
стовпці CITY міститься значення "New York". У стовпці SALES тієї ж рядки
міститься значення $ 692.000.000, яке є обсягом продажів нью-йоркського
офісу з початку року.
Всі значення, що містяться в одному і тому ж стовпці, є даними одного
типу. Наприклад, у стовпці CITY містяться лише слова, у стовпці SALES
містяться грошові суми, а в стовпці MGR містяться цілі числа,
представляють ідентифікатори службовців. Безліч значень, які можуть
утримуватися в стовпці, називається доменом цього стовпця. Доменом стовпця CITY
є безліч назв міст. Доменом стовпця SALES є будь-яка
грошова сума. Домен стовпця REGION складається всього з двох значень, "Eastern" і
"Western", оскільки у компанії всього два торгові регіону.
У кожного стовпця в таблиці є своє ім'я, яке часто слугує заголовком
стовпця. Всі стовпці в одній таблиці повинні мати унікальні імена, однак
дозволяється присвоювати однакові імена стовпців, розташованих в різних
таблицях. На практиці такі імена стовпців, як NAME, ADDRESS, QTY, PRICE і
SALES, часто зустрічаються в різних таблицях однієї бази даних.
Стовпці таблиці впорядковані зліва направо, і їх порядок визначається при
створенні таблиці. У будь-якій таблиці завжди є як мінімум один стовпчик. В
стандарті ANSI/ISO не вказується максимально допустиму кількість стовпців в
таблиці, однак майже в усіх комерційних СУБД ця межа існує і зазвичай
складає приблизно 255 стовпців.
На відміну від стовпців, рядки таблиці не мають певного порядку. Це
означає, що якщо послідовно виконати два однакових запиту для
відображення вмісту таблиці, немає гарантії, що обидва рази рядки будуть
перераховані в одному і тому ж порядку.
У таблиці може містити будь-яку кількість рядків. Цілком допустимо
існування таблиці з нульовим кількістю рядків. Така таблиця називається
порожній. Порожня таблиця зберігає структуру, визначену її стовпцями, просто в
ній не міститься дані. Стандарт ANSI/ISO не накладає обмежень на
кількість рядків у таблиці, і в багатьох СУБД розмір таблиць обмежений лише
вільним дисковим простором комп'ютера. В інших СУБД є максимальний
межа, проте він дуже високий - близько двох мільярдів рядків, а іноді й більше.
Первинні ключі
Оскільки рядки в реляційної таблиці не впорядковані, не можна вибрати рядок з
її номеру в таблиці. У таблиці немає "першого", "останньою" або "тринадцятої"
рядка. Тоді яким же чином можна вказати в таблиці конкретну рядок,
наприклад рядок для офісу, розташованого у Денвері?
У правильно побудованій реляційної бази даних у кожній таблиці є один або
кілька стовпців, значення в яких у всіх рядках різні. Цей стовпець
(стовпці) називається первинним ключем таблиці. Давайте знову подивимося на базу
даних, показану на рис. 1.6. На перший погляд, первинним ключем таблиці
OFFICES можуть служити і стовпець OFFICE, і стовпець CITY. Однак у випадку, якщо
компанія буде розширюватися і відкриє в будь-якому місті другий офіс, стовпець
CITY більше не зможе виконувати роль первинного ключа. На практиці в якості
первинних ключів таблиць звичайно треба вибирати ідентифікатори, такі як
ідентифікатор офісу (OFFICE в таблиці OFFICES), службовця (EMPL_NUM в таблиці
SALESREPS) та клієнта (CUST_NUM в таблиці CUSTOMES). А у випадку; з таблицею
ORDERS вибору немає - єдиним стовпцем, що містять унікальні значення,
є номер замовлення (ORDER_NUM).
Таблиця PRODUCTS, фрагмент якої показано на рис. 1.7, є прикладом
таблиці, в якій первинний ключ являє собою комбінацію стовпців. Такий
первинний ключ називається складовим. Стовпець MRF_ID містить ідентифікатори
виробників усіх товарів, перерахованих у таблиці, а стовпець PRODUCT_ID
містить номери, присвоєні товарах виробниками. Може здатися, що
стовпець PRODUCT_ID міг би й один виконувати роль первинного ключа, однак ніщо
не заважає двом різним виробникам присвоїти своїм виробам однакові
номера. Таким чином, як первинний ключ таблиці PRODUCTS необхідно
використовувати комбінацію стовпців MRF_ID і PRODUCT_ID. Для кожного з товарів,
що містяться в таблиці, комбінація значень в цих стовпцях буде унікальною.

Первинний ключ для кожного рядка таблиці є унікальним, тому в таблиці
з первинним ключем немає двох абсолютно однакових рядків. Таблиця, у якій усі
рядки відрізняються один від одного, в математичних термінах називається
ставленням. Саме цьому терміну реляційні бази даних і зобов'язані своїм
назвою, оскільки в їх основі лежать відносини (таблиці з відрізняються один
від одного рядками).
Хоча первинні ключі є важливою частиною реляційної моделі даних, в першу
реляційних СУБД (System/R, DB2, Oracle та інших) не була забезпечена явним
чином їх підтримка. Як правило, проектувальники бази даних самі стежили за
тим, щоб у всіх таблиць були первинні ключі, однак у самих СУБД не було
можливості визначити для таблиці первинний ключ. І тільки в СУБД DB2 Version
2, що з'явилася у квітні 1988 року, компанія IBM реалізувала підтримку первинних
ключів. Після цього така підтримка була додана в стандарт ANSI/ISO.
Відносини предок/нащадок
Однією з відмінностей реляційної моделі від перших моделей подання даних було
те, що в ній були відсутні явніпокажчики, які використовуються для реалізації
відносин предок/нащадок в ієрархічній моделі даних. Однак цілком очевидно,
що відносини предок/нащадок існують і в реляційних базах даних. Наприклад,
у нашій базі даних кожен із службовців закріплений за конкретним офісом, тому
ясно, що між рядками таблиці OFFICES і таблиці SALESREPS існує
ставлення. Чи не призводить чи відсутність явних покажчиків у реляційної моделі до
втрати інформації?
Як випливає з рис. 1.8, відповідь на це питання має бути негативним.

На малюнку зображено кілька рядків з таблиць OFFICES і SALESREPS. Звернемо
увагу на те, що в стовпці REP_OFFICE таблиці SALESREPS міститься
ідентифікатор офісу, в якому працює службовець. Доменом цього стовпця
(безліччю значень, які можуть в ньому зберігатися) є безліч
ідентифікаторів офісів, що містяться в стовпці OFFICE таблиці OFFICES. Те, в
якому офісі працює Мері Джонс (Магу Jones), можна дізнатися, визначивши значення
стовпця REP_OFFICE в рядку таблиці SALESREPS для Мері Джонс (число II) і потім
відшукавши в таблиці OFFICES рядок з таким же значенням у стовпці OFFICE (це для
офісу в Нью-Йорку). Таким же чином, щоб знайти всіх службовців нью-йоркського
офісу, слід запам'ятати значення стовпця OFFICE для Нью-Йорка (число II), а
потім переглянути таблицю SALESREPS і знайти всі рядки, в стовпці REP_OFFICE
яких міститься число 11 (це рядки для Мері Джонс і Сема Кларка (Sam
Clark)).
Відношення предок/нащадок, що існує між офісами і працюючими в них людьми,
в реляційної моделі не втрачено; просто воно реалізовано у вигляді однакових
значень даних, що зберігаються в двох таблицях, а не у вигляді явного покажчика. Всі
відносини, що існують між таблицями реляційної бази даних, реалізуються в
такому вигляді.
Зовнішні ключі
Стовпець однієї таблиці, значення в якому збігаються зі значеннями стовпчика,
що є первинним ключем іншої таблиці, називається зовнішнім ключем. На рис.
4.9 стовпець REP_OFFICE являє собою зовнішній ключ для таблиці OFFICES.
Значення, що містяться в цьому стовпці, являють собою ідентифікатори офісів.
Ці значення відповідають значенням у стовпці OFFICE, який є
первинним ключем таблиці OFFICES. Сукупно первинний і зовнішній ключі створюють
між таблицями, в яких вони містяться, таке ж відношення предок/нащадок,
як і в ієрархічній базі даних.
Зовнішній ключ, як і первинний ключ, теж може являти собою комбінацію
стовпців. На практиці зовнішній ключ завжди буде складовим (що складається з
декількох стовпців), якщо він посилається на складовою первинний ключ в іншій
таблиці. Очевидно, що кількість стовпців і їх типи даних у первинному та
зовнішньому ключах збігаються.
Якщо таблиця пов'язана з декількома іншими таблицями, вона може мати кілька
зовнішніх ключів. На рис. 1.9. показані три зовнішніх ключа таблиці ORDERS з
навчальної бази даних:

стовпець REP є зовнішнім ключем для таблиці SALESREPS і

пов'язує кожне замовлення з службовцям, які прийняли його;

стовпець CUST є зовнішнім ключем для таблиці CUSTOMES і

пов'язує кожне замовлення з клієнтом, що розмістили його;

стовпці MRF і PRODUCT сукупно є складовою зовнішній ключ для
таблиці PRODUCTS, який пов'язує кожне замовлення з замовленим товаром.



Відносини предок/нащадок, створені за допомогою трьох зовнішніх ключів в таблиці
ORDERS, можуть видатися знайомими. І дійсно, це ті ж самі відносини,
що і в мережевий базі даних, представленої на рис. 1.4. Як показує приклад,
реляційна модель даних має всі можливості мережевої моделі за частиною
вираження складних відносин.
Зовнішні ключі є невід'ємною частиною реляційної моделі, оскільки
реалізують відносини між таблицями бази даних. На жаль, як і у випадку з
первинними ключами, підтримка зовнішніх ключів була відсутня в першу реляційних
СУБД. Вона була введена в системі DB2 Version 2 і тепер є у всіх
комерційних СУБД.
Дванадцять правил Кодда
У статті, опублікованій в журналі "Computer World", Тед Коддом сформулював
дванадцять правил, яким повинна відповідати справжня реляційна база
даних. Дванадцять правил Кодда наведено в табл. 1.1. Вони є
напівофіційні визначенням поняття реляційна база даних. Перераховані
правила грунтуються на теоретичній роботі Кодда, присвяченій реляційної моделі
даних.

Таблиця 1.1. Дванадцять правил Кодда, яким повинна відповідати _
реляційна СУБД. _
1. Правило інформації. Вся інформація в базі даних повинна бути надана
виключно на логічному рівні і лише одним способом - у вигляді значень,
що містяться в таблицях.
2. Правило гарантованого доступу. Логічний доступ до всіх і кожного
елементу даних (атомарному значенню) в реляційної бази даних повинен
забезпечуватися шляхом використання комбінації імені таблиці, первинний ключ і
імені стовпця.
3. Правило підтримки недійсних значень. У цій реляційної базі
даних повинна бути реалізована підтримка недійсних значень, які
відрізняються від рядка символів нульової довжини, рядки пробільних символів, і від
нуля або будь-якого іншого числа і використовуються для подання відсутніх
даних незалежно від типу цих даних.
4. Правило динамічного каталогу, заснованого на реляційної моделі. Опис
бази даних на логічному рівні має бути представлено в тому ж вигляді, що і
основні дані, щоб користувачі, що володіють відповідними правами, могли
працювати з ним за допомогою того ж реляційного мови, який вони застосовують для
роботи з основними даними.
5.Право вичерпного под'язика даних. Реляційна система може
підтримувати різні мови і режими взаємодії з користувачем (наприклад,
режим запитань і відповідей). Однак повинен існувати принаймні одна мова,
оператори якого можна представити у вигляді рядків символів відповідно до
деяким чітко визначеним синтаксисом і який в повній мірі підтримує
наступні елементи: - визначення даних; - визначення уявлень; -
обробку даних (інтерактивну і програмну); - умови цілісності; -
ідентифікація прав доступу; - межі транзакцій (початок, завершення і скасування).
6. Правило оновлення уявлень. Всі вистави, які теоретично
можна оновити, повинні бути доступні для оновлення.
7. Правило додавання, оновлення та видалення. Можливість працювати зі ставленням
як з одним операндом повинна існувати не тільки при читанні даних, але і при
додавання, оновлення та видалення даних.
8. Правило незалежності фізичних даних. Прикладні програми й утиліти для
роботи з даними повинні на логічному рівні залишатися недоторканими за будь-яких
зміни способів зберігання даних або методів доступу до них.
9. Правило незалежності логічних даних. Прикладні програми й утиліти для
роботи з даними повинні на логічному рівні залишатися недоторканими при внесенні
в базові таблиці будь-яких змін, що теоретично дозволяють зберегти
недоторканими що містяться в цих таблицях дані.
10. Правило незалежності умов цілісності. Повинна існувати можливість
визначати умови цілісності, специфічні для конкретної реляційної бази
даних, на под'язике реляційної бази даних і зберігати їх у каталозі, а не в
прикладній програмі.
11. Правило незалежності розповсюдження. Реляційна СУБД не повинна залежати
від потреб конкретного клієнта.
12. Правило єдиності. Якщо в реляційної системі є низькорівневою мова
(обробляє один запис за один раз), то повинна бути відсутнім можливість
використання його для того, щоб обійти правила та умови цілісності,
виражені на реляційному мові високого рівня (обробному кілька
записів за один раз).

Правило 1 нагадує неформальне визначення реляційної бази даних,
наведене раніше.
Правило 2 вказує на роль первинних ключів при пошуку інформації в базі
даних. Ім'я таблиці дозволяє знайти потрібну таблицю, ім'я стовпця дозволяє
знайти потрібний стовпець, а первинний ключ дозволяє знайти рядок, що містить
шуканий елемент даних.
Правило 3 вимагає, щоб відсутні дані можна було уявити за допомогою
недійсних значень (NULL), які описані в розділі 5.
Правило 4 свідчить, що реляційна база даних повинна сама себе описувати.
Іншими словами, база даних повинна містити набір системних таблиць,
описують структуру самої бази даних. Ці таблиці описані в главі 16.
Правило 5 вимагає, щоб СУБД використовувала мова реляційної бази даних,
наприклад SQL, хоча явно SQL в правилі не згадується. Такий мова повинна
підтримувати всі основні функції СКБД - створення бази даних, читання і введення
даних, реалізацію захисту бази даних і т.д.
Правило 6 стосується уявлень, які є віртуальними таблицями,
дозволяють показувати різним користувачам різні фрагменти структури
бази даних. Це одне з правил, які складніше за все реалізувати на практиці.
Подання і проблеми їх оновлення описані в розділі 14.
Правило 7 акцентує увагу на тому, що бази даних за своєю природою
орієнтовані на безлічі. Воно вимагає, щоб операції додавання, видалення і
оновлення можна було виконувати над множинами рядків. Це правило призначене
для того, щоб заборонити реалізації, в яких підтримуються тільки операції
над одним рядком.
Правила 8 і 9 означають відділення користувачів та прикладної програми від
низькорівневою реалізації бази даних. Вони стверджують, що конкретні способи
реалізації зберігання чи доступу, які використовуються в СУБД, і навіть зміни структури
таблиць бази даних не повинні впливати на можливість користувача працювати з
даними.
Правило 10 говорить, що мова бази даних повинен підтримувати обмежувальні
умови, що накладаються на введені дані і дії, які можуть бути виконані
над даними.
Правило 11 говорить, що мова бази даних повинен забезпечувати можливість роботи з
розподіленими даними, розташованими на інших комп'ютерних системах.
Розподілені дані та проблеми управління ними описані в главі 20.
І, нарешті, правило 12 запобігає використання інших можливостей для
роботи з базою даних, крім мови бази даних, оскільки це може порушити її
цілісність.

2. Мова SQL як стандартну мову баз даних.

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


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

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

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

Читання даних. SQL дає користувачеві або додатком можливість читати з бази
даних містяться в ній дані і користуватися ними.

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

Управління доступом. За допомогою SQL можна обмежити можливості користувача
з читання та зміни даних і захистити їх від несанкціонованого доступу.

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

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

Таким чином, SQL є досить потужним мовою для взаємодії з СУБД.
По-друге, SQL - це не повноцінний комп'ютерний мова типу COBOL, FORTRAN або С.
У SQL немає оператора IF для перевірки умов, немає оператора GOTO для організації
переходів і немає операторів DO або FOR для створення циклів. SQL є
под'язиком баз даних, до якого входить близько тридцяти операторів,
призначених для керування базами даних. Оператори SQL вбудовуються в
базова мова, наприклад COBOL, FORTRAN або С, і дають можливість отримувати доступ
до баз даних. Крім того, з такої мови, як С, оператори SQL можна посилати
СУБД в явному вигляді, використовуючи інтерфейс викликів функцій.
Нарешті, SQL - це слабо структурований мова, особливо в порівнянні з такими
сильно структурованими мовами, як С або Pascal. Оператори SQL нагадують
англійські пропозиції і містять "слова-пустушки", які не впливають на зміст
оператора, але полегшують його читання. У SQL майже немає нелогічностей, до того ж
є ряд спеціальних правил, що запобігають створення операторів SQL, які
виглядають як абсолютно правильні, але не мають сенсу.
Незважаючи на не зовсім точна назва, SQL на сьогоднішній день є
єдиним стандартною мовою для роботи з реляційними базами даних. SQL -
це досить потужний і в той же час відносно легкий для вивчення мову.
Роль SQL
Сам по собі SQL не є ні системою керування базами даних, ні окремим
програмним продуктом. Не можна піти в комп'ютерний магазин і "купити SQL". SQL -
це невід'ємна частина СУБД, інструмент, за допомогою якого здійснюється зв'язок
користувача з нею. На рис. 2.2. зображена структурна схема типової СУБД,
компоненти якої з'єднуються в єдине ціле за допомогою SQL (свого роду
"клею").

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

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

SQL - мова програмування баз даних. Щоб отримати доступ до бази даних,
програмісти вставляють у свої програми команди SQL. Ця методика використовується
як у програмах, написаних користувачами, так і в службових програмах баз
даних (таких як генератори звітів і інструменти введення даних).

SQL - мова адміністрування баз даних. Адміністратор бази даних,
що знаходиться на міні-комп'ютері або на великій ЕОМ, використовує SQL для
визначення структури бази даних і управління доступом до даних.

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

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

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

Таким чином, SQL перетворився в корисний і потужний інструмент, що гарантує
людям, програмами і обчислювальних систем доступ до інформації, що міститься в
реляційних базах даних.
Переваги SQL
SQL - це легкий для розуміння мову і в той же час універсальне програмне
засіб управління даними.
Успіх мови SQL принесли наступні його особливості:
• незалежність від конкретних СУБД;
• переносимість з однієї обчислювальної системи на іншу;
• наявність стандартів;
• схвалення компанією IBM (СУБД DB2);
• підтримка з боку компанії Microsoft (протокол ODBC);
• реляційна основа;
• Високорівнева структура, що нагадує англійську мову;
• можливість виконання спеціальних інтерактивних запитів:
• програмного забезпечення доступу до баз даних;