Структура мови SQL Structured Query Language

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.


Нажми чтобы узнать.
скачати

Курсова робота з дисципліни "Бази даних"

на тему "Структура мови SQL"

Зміст

Введення

1 Поняття бази даних і СУБД

1.1 Предметна область

1.2 Концепція баз даних

1.2.1 Незалежність додатків від організації даних у зовнішній пам'яті

1.2.2 Ефективність організації даних

1.2.3 Інтеграція даних

1.2.4 Що таке база даних

2. Типи даних SQL

2.1 Таблиці SQL

2.2 Структура мови SQL

2.3 Оператори SQL

Висновок

Глосарій
Список використаних джерел

Додаток А


Введення

Одним з основних переваг реляційного підходу до організації баз даних (БД) є те, що користувачі реляційних БД отримують можливість ефективної роботи в термінах простих і наочних понять таблиць, їх рядків і стовпців без потреби знання реальної організації даних у зовнішній пам'яті.
Реляційна модель даних, що містить набір чітких розпоряджень до базової організації будь-якої реляційної системи управління базами даних (СКБД), дозволяє користувачам працювати в ненавігаційній манері, тобто для вибірки інформації з БД чоловік повинен всього лише вказати список цікавих для його таблиць і ті умови, яким повинні задовольняти обирані дані. СУБД приховує від користувача виконувані їй послідовні перегляди таблиць, виконуючи їх найбільш ефективним чином. Дуже важлива особливість реляційних систем полягає в тому, що результатом виконання будь-якого запиту до таблиць БД є також таблиця, яку можна зберегти в БД і / або по відношенню до якої можна виконувати нові запити.
Базовим вимогою до реляційних СУБД є наявність потужного і в теж час простої мови, що дозволяє виконувати всі необхідні користувачам операції. В останні роки таким повсюдно прийнятим мовою стала мова реляційних БД SQL - Structured Query Language (тепер все частіше назва мови розуміється як Standard Query Language).
До появи SQL в СУБД (незалежно від того, на якій моделі вони грунтувалися) доводилося підтримувати принаймні три мови, які зазвичай мали мало спільного: мова визначення даних (ЯОД), службовець для специфікації структур БД (зазвичай загальну структуру БД називають схемою БД ); мова маніпулювання даними (ЯМД), що дозволяє створювати прикладні програми, що взаємодіють з БД; і мова адміністрування БД (ЯАДБ), за допомогою якого можна було виконувати службові дії (наприклад, змінювати структуру БД або проводити її настройку з метою підвищення ефективності). Крім того, якщо потрібно було надати користувачам СУБД інтерактивний доступ до БД, доводилося вводити ще одну мову, оператори якого виконуються в діалоговому режимі. Мова SQL дозволяє вирішувати всі ці задачі.
Слід зазначити, що до достоїнств мови SQL відноситься наявність міжнародних стандартів. Перший міжнародний стандарт був прийнятий у 1989 р ., І відповідна версія мови називається SQL-89. Цей стандарт повністю підтримується практично у всіх сучасних комерційних реляційних СУБД (наприклад, в Informix, Sybase, Ingres, DB2 і т.д.). Стандарт SQL-89 в багатьох частинах має надзвичайно загальний характер і допускає дуже широке тлумачення. У цьому стандарті повністю відсутні такі важливі розділи, як маніпулювання схемою БД і динамічний SQL. Багато важливі аспекти мови відповідно до стандарту визначаються в реалізації.
Можливо, найбільш важливими досягненнями стандарту SQL-89 є чітка стандартизація синтаксису і семантики операторів вибірки і маніпулювання даними і фіксація засобів обмеження цілісності БД, що включають можливості визначення первинного і зовнішніх ключів відносин і так званих перевірочних обмежень цілісності, що дозволяють сформулювати умову для кожної окремої рядка таблиці . Засоби визначення зовнішніх ключів дозволяють легко формулювати вимоги так званої цілісності БД по посиланнях. Формулювання обмежень цілісності на основі поняття зовнішнього ключа проста і зрозуміла.
Усвідомлюючи неповноту стандарту SQL-89, на тлі завершення розробки цього стандарту фахівці різних фірм почали роботу над стандартом SQL2. Ця робота також тривала багато років, було випущено кілька проектів стандарту, поки, нарешті, у березні 1992 р . не був вироблений остаточний проект стандарту (після чого стандарт і відповідна мова стали називати SQL-92). Цей стандарт істотно більш повний і охоплює практично всі необхідні для реалізації аспекти: маніпулювання схемою БД, управління транзакціями і сесіями (сесія - це послідовність транзакцій, в межах якої зберігаються тимчасові відносини), підключення до БД, динамічний SQL. Нарешті стандартизовані відносини-каталоги БД, що взагалі-то не пов'язане з мовою безпосередньо, але дуже сильно впливає на реалізацію. Зауважимо, що в стандарті представлені три рівні мови - базовий, проміжний і повний. Протягом декількох років після прийняття стандарту виробники СУБД, стверджували сумісність своїх продуктів із стандартом, насправді в кращому разі підтримували проміжний рівень мови SQL-92 (природно, з власними розширеннями). Тільки в останніх випусках СУБД провідних виробників забезпечується сумісність з повним варіантом мови. Нарешті, одночасно із завершенням робіт з визначення стандарту SQL-92 була почата розробка стандарту SQL3. Загальною точкою зору провідних виробників СУБД є те, що майбутні продукти, маючи більш розвиненими можливостями, повинні бути сумісні з попередніми випусками. Хоча багато розробників і користувачі реляційних СУБД усвідомлюють наявність багатьох непереборних недоліків мови SQL, від нього тепер уже неможливо відмовитися (як неможливо відмовитися від використання мови Сі в процедурному програмуванні). Отже, потрібен новий стандарт мови, що забезпечує такі очевидно необхідні можливості як визначувані користувачами типи даних, розвиненіші засоби визначення таблиць, наявність повного механізму тригерів і т.д. Потрібен саме стандарт, а не наявність розвинених приватних версій мови, оскільки це вигідно і виробникам і користувачам СУБД.

1 Поняття бази даних і СУБД

1.1 Предметна область

Основним призначенням інформаційних систем є зберігання відомостей про навколишній світ і процеси, які відбуваються в ньому, які в кінцевому підсумку надаються користувачам. Поскольку для різних групп людей інтерес представляют только определенние частини реального світу, то і дані кожної інформаціонной сістеми будуть відноситься к певній галузі. Частина реальної системи, що підлягає дослідженню з метою її опису звані предметні областю.
Розрізняють повну предметну область і її фрагменти, при цьому кожен фрагмент може представляти свою предметну область. Наприклад, для університету можна виділити наступні фрагменти: навчальний відділ, бухгалтерія, відділ кадрів, бюро розкладів і т. д.
Інформація, необхідна для опису предметної області, може включати відомості про людей, предмети, документи, події, поняттях і т.д.
Кожна предметна область характеризується безліччю об'єктів - елементів реальних систем і процесів, які використовують об'єкти, а також безліччю користувачів, якi характеризуються єдиним поглядом на предметну область. Зокрема, для бухгалтерії об'єкти - всілякі документи. Процеси бухгалтерії - розрахунок заробітної плати, матеріальний облік, облік банківських операцій і ін Нарешті користувачі цього фрагмента працівники бухгалтерії, працівники фінансових органів, керівники підприємства і т. д.
Кожен об'єкт має певним набором властивостей, які запам'ятовуються в інформаційній системі. При обробці даних часто доводиться мати справу з сукупністю однорідних об'єктів, наприклад, таких, як студенти або факультети, і записувати інформацію про одних і тих же властивості для кожного з них. Сукупність об'єктів, що володіють однаковим набором властивостей, називається класом об'єктів. Для об'єктів одного класу набір властивостей буде однаковий, хоча значення цих властивостей для кожного об'єкта можуть бути різними.
Часто клас об'єктів називається сутністю. Кожна сутність має атрибутами. Атрибут - це властивість об'єкта, що характеризує його примірник. Сутність "студент" може мати атрибути "ім'я", "рік народження", "дата надходження" і т. д. Таким чином сутність можна визначити, як безліч індивідуальних об'єктів одного типу (примірників), причому всі ці об'єкти різні, тобто . набір атрибутів однаковий, а їх значення різні.

1.2 Концепція баз даних

1.2.1 Незалежність додатків від організації даних у зовнішній пам'яті

Основою будь-якої інформаційної системи є збережені в ній дані. У загальному випадку дані - це інформація, підготовлена ​​для певних цілей, при цьому часто мається на увазі певний формат перетворення.
У всі часи люди фіксували дані на тому або іншому матеріальному носії (папір, камінь і т. д.) Зазвичай дані фіксуються спільно з їх інтерпретацією (семантікойxe "семантика"), оскільки системи писемності природних мов дозволяє це робити досить гнучко. Наприклад, запис на папері "Заробітна плата - 1000" містить дане - "1000" і його семантику (сенс) - "Заробітна плата".
Досить часто дані та їх інтерпретація бувають розділені. Вони можуть бути відображені в різних частинах носія (наприклад, таблиці, в яких сенс записується у верхніх рядках, а самі дані в наступних) і більше того можуть знаходитися на різних носіях. Такий поділ істотно ускладнює роботу з даними.
Застосування ЕОМ для обробки і зберігання даних привело до ще більшого розділення даних і интерпретирующей інформації. Так як на ранніх етапах розвитку обчислювальної техніки її можливості були дуже обмежені, пам'ять використовувалася тільки для зберігання самих даних. Опис ж даних (порядок, тип даних, довжина) перебували у програмах, які таким чином "знали", наприклад, що з починаючи певного байта адресного простору зовнішньої пам'яті чотири байти містять дане в числовому форматі, пов'язане із заробітною платою, а наступні 30 байтів в текстовому форматі - містять прізвище співробітника.
Така залежність між даними і програмою, суттєво обмежує можливості та ефективність інформаційних систем.
У першу чергу це проявляється, коли виникає необхідність в модифікації інформаційної системи. Уявіть собі ситуацію, коли до деякого файлу звертаються кілька програм. У певний момент часу в предметній області відбулися зміни, які у свою чергу зажадали зміни структури записів файла, наприклад додавання нових полів до запису файлу або зміна довжини деяких полів. У цьому випадку доведеться переробляти всі програми, навіть якщо деяким з них, для виконання своїх функцій нові або змінені поля не потрібні.
З цієї причини часто для окремих програм створювалися свої набори даних, не дивлячись на те, що характер інформації що зберігалася в них був частково або повністю однаковим. Таке багаторазове дублювання призводило або до невідповідності даних станом предметної області або до протиріччя одних даних іншим.
Сучасний підхід вимагає, щоб опис даних було незалежним від програм користувачів, а деяка система керування даними, яка використовуючи ці описи, розміщує їх у зовнішній пам'яті і згодом "знає" де і як вони зберігаються, забезпечувала б автоматичний інтерфейс між даними і додатками. У цьому випадку стає можливим, в програмах задавати тільки імена необхідних для обробки даних і формати їх подання, у зв'язку з чим зміни в організації даних істотно не відображаються на прикладному програмному забезпеченні.
Описи даних часто зберігаються разом з самими даними і називаются метаданими. У ряді сучасних систем метадані, що містять також інформацію про користувачів, права доступу, статистику звернення до даних та інші відомості, зберігаються в словнику даних.
Такий підхід дозволяє маніпулювати даними досить гнучко і не вимагає значних зусиль при розширенні та модифікації інформаційних систем.

1.2.2 Ефективність організації даних

Припустимо, що ми хочемо реалізувати інформаційну систему, що підтримує Облік студентів університету. Система повинна виконувати наступні дії: видавати списки студентів по факультетах і групам, підтримувати можливість переведення студента з однієї групи в іншу, прийому нових студентів і виключення учнів. Для кожного факультету повинна підтримуватися можливість отримання імені декана цього факультету, а для групи ім'я куратора, загальної чисельності факультету, і т.д.
Припустимо, ми вирішили створювати цю інформаційну систему використовуючи деяку файлову систему, в якій користувачі представляють файл як послідовність записів. Кожна запис - це послідовність байтів постійного або змінного розміру. Записи можна читати або записувати послідовно, позиціонувати файл на запис із зазначеним номером, структурувати на поля і оголошувати деякі поля ключами запису. Крім того, є можливість вибірки запису з файлу за її заданому ключу. Природно, що в цьому випадку файлова система підтримує в тому ж (або іншому, службовому) базовому файлі додаткові, невидимі користувачеві, службові структури даних. Поширені способи організації ключових файлів грунтуються на техніці хешування і B-дерев.
Для зберігання даних будемо використовувати один файл СТУДЕНТИ. Оскільки об'єктом предметної області у нашому випадку є студент, визначаємо, щоб у цьому файлі містилася одна запис для кожного студента. Виходячи з вимог до інформаційної системи, позначимо набір властивостей, що описує об'єкт і відобразимо його наступними полями у файлі:
ФІО_СТУДЕНТА,
АДРЕСА,
Дата_народження,
НАІМНОВАНІЕ_ФАКУЛЬТЕА,
ФІО_ДЕКАНА,
НОМЕР_ГРУППИ,
ФІО_КУРАТОРА.
Функції нашої інформаційної системи вимагають, щоб забезпечувалася можливість многоключевого доступу до записів цього файлу за значеннями унікального ключа ФІО_СТУДЕНТА. Крім того, повинна забезпечуватися можливість вибору всіх записів із загальним значенням НАІМЕНОВАНІЕ_ФАКУЛЬТЕТА і НОМЕР_ГРУППИ тобто доступ по неунікальним ключу.
Не важко помітити, що така організація даних спричиняє суттєву надмірність зберігання даних (для кожного студента однієї групи повторюється ім'я куратора, а для студентів одного факультету найменування факультету та ім'я декана). Крім того, якщо в ході експлуатації системи на будь-якому факультеті поміняється декан, доведеться вносити зміни до декількох сотнях записів, а для того щоб одержати чисельність факультету, кожен раз при виконанні такої функції треба буде вибрати всі записи з заданим значенням найменування факультету і порахувати їх кількість.
Аналіз предметної області показує, що можна виділити ще два класи об'єктів ФАКУЛЬТЕТИ і ГРУПИ з притаманними тільки їм властивостями (для факультетів - декани, а для груп - куратори). Природно припустити, що інформація про кожен об'єкт має бути в окремому файлі. Тому наша систем буде складатися з трьох файлів СТУДЕНТИ, ФАКУЛЬТЕТИ, ГРУПИ, з наступною організацією записів:
СТУДЕНТИ:
СТУД_ФІО_СТУДЕНТА,
СТУД_АДРЕС,
СТУД_ДАТА_РОЖДЕНІЯ,
СТУД_НОМЕР_ГРУППИ.
ГРУПИ:
ГРУП_НОМЕР_ГРУППИ,
ГРУП_ФІО_КУРАТОРА,
ГРУП_ИДЕНТИФИКАТОР_ФАКУЛЬТЕА,
ГРУП_КОЛІЧЕСТВО_СТУДЕНТОВ.
ФАКУЛЬТЕТИ:
ФАК_ИДЕНТИФИКАТОР_ФАКУЛЬТЕА,
ФАК_НАІМНОВАНІЕ_ФАКУЛЬТЕА,
ФАК_ФІО_ДЕКАНА,
ФАК_КОЛІЧЕСТВО_СТУДЕНТОВ;
Поле СТУД_НОМЕР_ГРУППИ додано в файл СТУДЕНТИ, а ГРУП_ИДЕНТИФИКАТОР_ФАКУЛЬТЕТА в файл ГРУПИ для встановлення зв'язків між файлами. Так наприклад, по значенням поля ГРУП_ИДЕНТИФИКАТОР_ФАКУЛЬТЕТА у файлі ГРУПИ можна визначити до якого факультету належить та чи інша група. Інакше кажучи, один файл посилається на інший, поля ж, що використовується для посилань називається ключем.
Такий механізм встановлення інформаційних зв'язків між файлами називається механізмом дублювання ключів. Таким чином, кожен з файлів буде містити тільки не дубльовану інформацію, необхідності в динамічних обчисленнях сумарної інформації не виникає.
Однак тепер система повинна тепер "знати", що вона працює з трьома інформаційно пов'язаними файлами, повинна знати структуру і зміст кожного поля (наприклад, що ГРУП_ ДЕНТІФІКАТОР_ ФАКУЛЬТЕТУ і ФАК_ ІДЕНТІФІКАТОР_ФАКУЛЬТЕТА означають одне й те саме), а також розуміти, що в ряді випадків зміна інформації в одному файлі має автоматично викликати модифікацію в інших, щоб їх загальний вміст було узгодженим.
Наприклад, якщо на факультет приймається новий студент, то необхідно додати запис в файл СТУДЕНТ, а також відповідним чином змінити поля ФАК_КОЛІЧЕСТВО_СТУДЕНТОВ і ГРУП_КОЛІЧЕСТВО_СТУДЕНТОВ у файлах ФАКУЛЬТЕТИ і ГРУПИ. Інакше кажучи дані у всіх файлах повинні бути узгодженими.
Поняття узгодженості даних є ключовим поняттям баз даних. Фактично, якщо інформаційна система (навіть така проста, як у нашому прикладі) підтримує узгоджене зберігання інформації в декількох файлах, можна говорити про те, що вона підтримує базу даних.
Зрозуміло, що навіть для такої простої системи її реалізація традиційними методами програмування, вимагає від розробників створення досить складних процедур, які пов'язують окремі файли в єдине ціле.
Для підтримки узгодженості даних в декількох файлах недостатньо бібліотеки процедур, необхідно, щоб така система мала деякі власні дані (метадані) і навіть знання, що визначають цілісність даних.
Якщо деяка допоміжна система керування даними дозволяє працювати з декількома файлами, забезпечуючи їх узгодженість, можна назвати її системою управління базами даних.

1.2.3 Інтеграція даних

В інформаційних системах реалізованих на безлічі локальних додатків, кожне з яких використовує свій набір даних, має місце надмірність (дублювання) даних. Внаслідок цього синхронне підтримка даних для всіх додатків стає вельми проблематичним, що в може призвести до неправильного відображенню стану предметної області і викликати досить неприємні наслідки.
Розглянемо наступний приклад для двох додатків "Облік кадрів" і "Розрахунок заробітної плати" для яких необхідні такі відомості:
Облік кадрів
Розрахунок заробітної плати
Табельний номер
Табельний номер
П. І. Б. Співробітника
П. І. Б. Співробітника
Відділ
Відділ
Посада
Посадовий оклад
Стаж роботи
Стаж роботи
Рік народження
За правилами предметної області спочатку інформація про переведення працівника на нову посаду або в інший відділ, а так само про звільнення надходить у відділ кадрів. Якщо ж з яких-небудь причин про це не буде своєчасно відомо в бухгалтерії, то в кращому випадку прізвище цього співробітника виявиться не в тій відомості або ж виникне зовсім курйозне становище, коли звільненому працівникові буде нарахована заробітна плата.
Тому існує необхідність у створенні системи з єдиним сховищем даних, в якій всі дані накопичуються і зберігаються централізовано, а інформація внесена одним користувачем стає доступною для інших. У пам'яті ЕОМ повинна бути створена динамічно оновлювана модель предметної області це значить, що відповідність бази даних поточному стану предметної області забезпечується не періодично, а в режимі реального часу. Завдяки інтеграції усувається дублювання даних, підвищується рівень їх достовірності, спрощуються і стають ефективніше процедури оновлення даних. Інтеграція даних породжує ряд проблем, які ми розглянемо нижче.

1.2.4 Що таке база даних

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

2. Типи даних SQL
У SQL використовуються такі основні типи даних, формати яких можуть дещо відрізнятися для різних СУБД:
INTEGER
- Ціле число (зазвичай до 10 значущих цифр і знак);
SMALLINT
- "Коротке ціле" (звичайно до 5 значущих цифр і знак);
DECIMAL (p, q)
- Десяткове число, яке має p цифр (0 <p <16) і знак; за допомогою q задається число цифр праворуч від десяткової крапки (q <p, якщо q = 0, воно може бути опущено);
FLOAT
- Дійсне число з 15 значущими цифрами та цілочисловим порядком, визначеним типом СУБД;
CHAR (n)
- Символьний рядок фіксованої довжини з n символів (0 <n <256);
VARCHAR (n)
- Символьний рядок змінної довжини, що не перевищує n символів (n> 0 і різне в різних СУБД, але не менше 4096);
DATE
- Дата в форматі, визначеному спеціальною командою (за замовчуванням mm / dd / yy); поля дати можуть містити тільки реальні дати, що починаються за кілька тисячоліть до н.е. і обмежені п'ятим-десятим тисячоліттям н.е.;
TIME
- Час у форматі, визначеному спеціальною командою, (за замовчуванням hh.mm.ss);
DATETIME
- Комбінація дати і часу;
MONEY
- Гроші в форматі, що визначає символ грошової одиниці ($, руб, ...) і його розташування (суфікс чи префікс), точність дробової частини і умова для показу грошового значення.
У деяких СУБД ще існує тип даних LOGICAL, DOUBLE і ряд інших. СУБД INGRES надає користувачеві можливість самостійного визначення нових типів даних, наприклад, площинні або просторові координати, одиниці різних метрик, п'яти-або шестиденні тижня (робочий тиждень, де відразу після п'ятниці або суботи слід понеділок), дробу, графіка, великі цілі числа (що стало дуже актуальним для російських банків) і т.п.

2.1 Таблиці SQL

До цих пір поняття "таблиця", як правило, пов'язувалося з реальною або базової таблицею, тобто c таблицею, для кожного рядка якій насправді є деякий двійник, що зберігається у фізичній пам'яті машини (Додаток А). Однак SQL використовує і створює ряд віртуальних (начебто існуючих) таблиць: поглядів, курсорів та неіменованим робочих таблиць, в яких формуються результати запитів на отримання даних з базових таблиць і, можливо, уявлень. Це таблиці, які не існують в базі даних, але як би існують з точки зору користувача.
Базові таблиці створюються за допомогою пропозиції CREATE TABLE (створити таблицю). Тут же наведемо приклад пропозиції для створення опису таблиці Страви:
CREATE TABLE Страви
(БЛ SMALLINT,
Страва CHAR (70),
У CHAR (1),
Основа CHAR (10),
Вихід FLOAT,
Праця SMALLINT);
Пропозиція CREAT TABLE специфікує ім'я базової таблиці, яка повинна бути створена, імена її шпальт і типи даних для цих стовпців (а також, можливо, деяку додаткову інформацію, не иллюстрируемого даними прикладом). CREAT TABLE - виконується пропозицію. Якщо його ввести з терміналу, система одразу побудує таблицю Страви, яка спочатку буде порожнім: вона буде містити тільки рядок заголовків стовпців, але не буде ще утримувати ніяких рядків з даними.

2.2 Структура мови SQL

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

2.3 Оператори SQL

Основу мови SQL складають оператори, умовно розбиті не декілька груп по виконуваних функцій.
Можна виділити наступні групи операторів (перераховані не всі оператори SQL):
Оператори DDL (Data Definition Language) - оператори визначення об'єктів бази даних
CREATE SCHEMA - створити схему бази даних
DROP SHEMA - видалити схему бази даних
CREATE TABLE - створити таблицю
ALTER TABLE - змінити таблицю
DROP TABLE - видалити таблицю
CREATE DOMAIN - створити домен
ALTER DOMAIN - змінити домен
DROP DOMAIN - видалити домен
CREATE COLLATION - створити послідовність
DROP COLLATION - видалити послідовність
CREATE VIEW - створити уявлення
DROP VIEW - видалити уявлення
Оператори DML (Data Manipulation Language) - оператори маніпулювання даними
SELECT - відібрати рядки з таблиць
INSERT - додати рядки в таблицю
UPDATE - змінити рядки в таблиці
DELETE - видалити рядки в таблиці
COMMIT - зафіксувати внесені зміни
ROLLBACK - відкотити внесені зміни
Оператори захисту і управління даними
CREATE ASSERTION - створити обмеження
DROP ASSERTION - видалити обмеження
GRANT - надати привілеї користувачеві або додатка на маніпулювання об'єктами
REVOKE - скасувати привілеї користувача або програми
Крім того, є групи операторів установки параметрів сеансу, отримання інформації про базу даних, оператори статичного SQL, оператори динамічного SQL.
Найбільш важливими для користувача є оператори маніпулювання даними (DML).
Приклади використання операторів маніпулювання даними
INSERT - вставка рядків у таблицю
Приклад 1. Вставка одного рядка в таблицю:
INSERT INTO
P (PNUM, PNAME)
VALUES (4, "Іванов");
Оператор SELECT є фактично самим важливим для користувача і найскладнішим оператором SQL. Він призначений для вибірки даних з таблиць, тобто він, власне, і реалізує одне їх основних призначення бази даних - надавати інформацію користувачеві.
Оператор SELECT завжди виконується над деякими таблицями, що входять в базу даних.
Насправді в базах даних можуть бути не лише постійно зберігаються таблиці, а також тимчасові таблиці і так звані подання. Подання - це просто зберігаються в базі дані SELECT-вирази. З точки зору користувачів подання - це таблиця, яка не зберігається постійно в базі даних, а "виникає" у момент звернення до неї. З точки зору оператора SELECT і постійно зберігаються таблиці, і тимчасові таблиці та подання виглядають абсолютно однаково. Звичайно, при реальному виконанні оператора SELECT системою враховуються розбіжності між збереженими таблицями і уявленнями, але ці відмінності приховані від користувача.
Результатом виконання оператора SELECT завжди є таблиця. Таким чином, за результатами дій оператор SELECT схожий на оператори реляційної алгебри. Будь-який оператор реляційної алгебри може бути виражений відповідним чином сформульованим оператором SELECT. Складність оператора SELECT визначається тим, що він містить у собі всі можливості реляційної алгебри, а також додаткові можливості, яких в реляційній алгебрі немає.
Відбір даних з однієї таблиці
Приклад. Вибрати всі дані з таблиці постачальників (ключові слова SELECT ... FROM ...):
SELECT *
FROM P;
Іноді доводиться виконувати запити, в яких таблиця з'єднується сама з собою, або одна таблиця з'єднується двічі з іншою таблицею. При цьому використовуються імена кореляції (аліаси, псевдоніми), які дозволяють розрізняти сполучаються копії таблиць. Імена кореляції вводяться в розділі FROM і йдуть через пробіл після імені таблиці. Імена кореляції повинні використовуватися в якості префікса перед ім'ям стовпця і відділяються від імені стовпця точкою. Якщо в запиті вказуються одні й ті ж поля з різних примірників однієї таблиці, вони повинні бути перейменовані для усунення неоднозначності в іменуванні колонок результатірующей таблиці. Визначення імені кореляції діє тільки під час виконання запиту.
Приклад. Відібрати всі пари постачальників таким чином, щоб перший постачальник в парі мав статус, більший статусу другого постачальника:
SELECT
P1.PNAME AS PNAME1,
P1.PSTATUS AS PSTATUS1,
P2.PNAME AS PNAME2,
P2.PSTATUS AS PSTATUS2
FROM
P P1, P P2
WHERE P1.PSTATUS1> P2.PSTATUS2;
Опишемо синтаксис оператора вибірки даних (оператора SELECT) більш точно. При описі синтаксису операторів зазвичай використовуються умовні позначення, відомі як стандартні форми Бекуса-Наура (BNF).
У BNF позначеннях використовуються наступні елементи:
Символ "::=" означає рівність за визначенням. Зліва від знаку варто визначається поняття, праворуч - власне визначення поняття.
Ключові слова записуються великими літерами. Вони зарезервовані і складають частину оператора.
Мітки-заповнювачі конкретних значень елементів і змінних записуються курсивом.
Необов'язкові елементи оператора укладені в квадратні дужки.
Вертикальна риса | вказує на те, що всі попередні їй елементи списку є необов'язковими і можуть бути замінені будь-яким іншим елементом списку після цієї риси.
Фігурні дужки {} вказують на те, що все що знаходиться всередині них є єдиним цілим.
Три крапки "..." означає, що попередня частина оператора може бути повторена будь-яку кількість разів.
Три крапки, всередині якого знаходиться кома ".,.." вказує, що попередня частина оператора, що складається з декількох елементів, розділених комами, може мати довільне число повторень. Кому не можна ставити після останнього елемента. Зауваження: дана угода не входить в стандарт BNF, але дозволяє більш точно описати синтаксис операторів SQL.
Круглі дужки є елементом оператора.
Синтаксис оператора вибірки
У досить сильно спрощеному вигляді оператор вибірки даних має наступний синтаксис (для деяких елементів ми дамо не BNF-визначення, а словесний опис):
Оператор вибірки:: =
Табличне вираження
[ORDER BY
{{Ім'я стовпця-результату [ASC | DESC]} | {Позитивне ціле [ASC | DESC ]}}.,..];
Табличне вираз:: =
Select-вираз
[
{UNION | INTERSECT | EXCEPT} [ALL]
{Select-вираз | TABLE Ім'я таблиці | Конструктор значень таблиці}
]
Select-вираз:: =
SELECT [ALL | DISTINCT]
{{{Скалярний вираз | Функція агрегування | Select-вираз} [AS Ім'я стовпця ]}.,..}
| {{Ім'я таблиці | Ім'я кореляції} .*}
| *
FROM {
{Ім'я таблиці [AS] [Ім'я кореляції] [(Ім'я стовпця .,..)]}
| {Select-вираз [AS] Ім'я кореляції [(Ім'я стовпця .,..)]}
| З'єднана таблиця }.,..
[WHERE Умовний вираз]
[GROUP BY {[{Ім'я таблиці | Ім'я кореляції}.] Ім'я стовпця }.,..]
[HAVING Умовний вираз]
Select-вираз в розділі SELECT, що використовується в якості значення для отбираемого стовпця, має повертати таблицю, що складається з одного рядка і одного стовпця, тобто скалярний вираз. Умовний вираз в розділі WHERE має обчислюватися для кожного рядка, що є кандидатом у результатірующее безліч рядків. В цьому умовному вираженні можна використовувати вкладені запити. Синтаксис умовних виразів, допустимих в розділі WHERE розглядається нижче.
Розділ HAVING містить умовний вираз, що обчислюється для кожної групи, яка визначається списком угруповання в розділі GROUP BY. Це умовний вираз може містити функції агрегування, обчислювані для кожної групи. Умовний вираз, сформульоване в розділі WHERE, може бути перенесено в розділ HAVING. Перенесення умов з розділу HAVING в розділ WHERE неможливий, якщо умовний вираз містить агрегатні функції. Перенесення умов з розділу WHERE в розділ HAVING є поганим стилем програмування - ці розділи призначені для різних за змістом умов (умови для рядків і умови для груп рядків). Якщо в розділі SELECT присутні агрегатні функції, то вони обчислюються по-різному в залежності від наявності розділу GROUP BY. Якщо розділ GROUP BY відсутній, то результат запиту повертає не більше одного рядка. Агрегатні функції обчислюються за всіма рядками, що задовольняє умовного виразу в розділі WHERE. Якщо розділ GROUP BY присутній, то агрегатні функції обчислюються окремо для кожної групи, визначеної в розділі GROUP BY.
Скалярний вираз - як скалярних виразів у розділі SELECT можуть виступати або імена стовпців таблиць, що входять до розділу FROM, або прості функції, які повертають скалярні значення.
Функція агрегування:: =
COUNT (*) |
{
{COUNT | MAX | MIN | SUM | AVG} ([ALL | DISTINCT] Скалярний вираз)
}
Конструктор значень таблиці:: =
VALUES Конструктор значень рядка., ..
Конструктор значень рядка:: =
Елемент конструктора | (Елемент конструктора .,..) | Select-вираз
Зауваження. Select-вираз, що використовується в конструкторі значень рядка, зобов'язане повертати рівно один рядок.
Елемент конструктора:: =
Вираз для обчислення значення | NULL | DEFAULT
Синтаксис з'єднаних таблиць
У розділі FROM оператора SELECT можна використовувати з'єднані таблиці. Нехай у результаті деяких операцій ми отримуємо таблиці A і B. Такими операціями можуть бути, наприклад, оператор SELECT або інша поєднана таблиця. Тоді синтаксис з'єднаної таблиці має наступний вигляд:
З'єднана таблиця:: =
Перехресне з'єднання
| Природний з'єднання
| Поєднання за допомогою предиката
| Поєднання за допомогою імен стовпців
| Поєднання об'єднання
Тип з'єднання:: =
INNER
| LEFT [OUTER]
| RIGTH [OUTER]
| FULL [OUTER]
Перехресне підключення:: =
Таблиця А CROSS JOIN Таблиця В
Природне з'єднання:: =
Таблиця А [NATURAL] [Тип з'єднання] JOIN Таблиця в
З'єднання за допомогою предиката:: =
Таблиця А [Тип з'єднання] JOIN Таблиця в ON Предикат
З'єднання за допомогою імен стовпців:: =
Таблиця А [Тип з'єднання] JOIN Таблиця В USING (Ім'я стовпця .,..)
З'єднання об'єднання:: =
Таблиця А UNION JOIN Таблиця В
Опишемо використовувані терміни.
CROSS JOIN - Перехресне з'єднання повертає просто декартово твір таблиць. Таке з'єднання в розділі FROM може бути замінено списком таблиці через кому.
NATURAL JOIN - Природне з'єднання виробляється за всіма стовпцями таблиці А і В, які мають однакові імена. У результатірующую табліцу однакові стовпці вставляються лише один раз.
JOIN ... ON - З'єднання за допомогою предиката з'єднує рядки таблиць А і В за допомогою зазначеного предиката.
JOIN ... USING - З'єднання за допомогою імен стовпців з'єднує відносини подібно до природного з'єднанню за тими спільним стовпцях таблиць А і Б, які вказані у списку USING.
OUTER - Ключове слово OUTER (зовнішній) не є обов'язковими, воно не використовується ні в яких операціях з даними.
INNER - Тип з'єднання "внутрішнє". Внутрішній тип з'єднання використовується за умовчанням, коли тип явно не заданий. У таблицях А і В з'єднуються тільки ті рядки, для яких знайдений збіг.
LEFT (OUTER) - Тип з'єднання "ліве (зовнішнє)". Ліве з'єднання таблиць А і В включає в себе всі рядки з лівої таблиці А і ті рядки з правої таблиці В, для яких виявлено збіг. Для рядків з таблиці А, для яких не знайдено відповідності в таблиці В, в стовпці, які добувають із таблиці В, заносяться значення NULL.
RIGHT (OUTER) - Тип з'єднання "праве (зовнішнє)". Праве з'єднання таблиць А і В включає в себе всі рядки з правої таблиці В і ті рядки з лівої таблиці А, для яких виявлено збіг. Для рядків з таблиці В, для яких не знайдено відповідності в таблиці А, у стовпці, які добуваються з таблиці А заносяться значення NULL.
FULL (OUTER) - Тип з'єднання "повне (зовнішнє)". Це комбінація лівого і правого з'єднань. У повне з'єднання включаються всі рядки з обох таблиць. Для співпадаючих рядків поля заповнюються реальними значеннями, для незбіжних рядків поля заповнюються відповідно до правил лівого і правого з'єднань.
UNION JOIN - З'єднання об'єднання є зворотним по відношенню до внутрішнього з'єднанню. Воно включає тільки ті рядки з таблиць А і В, для яких не знайдено збігів. У них використовуються значення NULL для стовпців, отриманих з іншої таблиці. Якщо взяти повне зовнішнє з'єднання і видалити з нього рядки, отримані в результаті внутрішнього сполучення, то вийде з'єднання об'єднання.
Використання з'єднаних таблиць часто полегшує сприйняття оператора SELECT, особливо, коли використовується природне з'єднання. Якщо не використовувати з'єднані таблиці, то при виборі даних з декількох таблиць необхідно явно вказувати умови сполучення в розділі WHERE. Якщо при цьому користувач вказує складні критерії відбору рядків, то в розділі WHERE змішуються семантично різні поняття - як умови зв'язку таблиць, так і умови відбору рядків (див. приклади 13, 14, 15 цієї глави).
Синтаксис умовних виразів розділу WHERE
Умовний вираз, що використовується в розділі WHERE оператора SELECT повинна обчислюватися для кожного рядка-кандидата, що відбирається оператором SELECT. Умовний вираз може повертати одне з трьох значень істинності: TRUE, FALSE або UNKNOUN. Рядок-кандидат відбирається в результатірующее безліч рядків тільки в тому випадку, якщо для неї умовний вираз повернуло значення TRUE.
Умовні вирази мають наступний синтаксис (з метою спрощення викладу наведені не всі можливі предикати):
Умовний вираз:: =
[(] [NOT]
{Предикат порівняння
| Предикат between
| Предикат in
| Предикат like
| Предикат null
| Предикат кількісного порівняння
| Предикат exist
| Предикат unique
| Предикат match
| Предикат overlaps}
[{AND | OR} Умовний вираз] [)]
[IS [NOT] {TRUE | FALSE | UNKNOWN}]
Предикат порівняння:: =
Конструктор значень рядка {= | <|> | <= |> = | <>} Конструктор значень рядка
Предикат LIKE здійснює пошук рядка-пошуку в рядку-шаблоні. У рядку-шаблоні дозволяється використовувати два трафаретних символу:
Символ підкреслення "_" може використовуватися замість будь-якого одиничного символу в рядку-пошуку,
Символ відсотка "%" може заміняти набір будь-яких символів в рядку пошуку (число символів в наборі може бути від 0 і більше).
Предикат null:: =
Конструктор значень рядка IS [NOT] NULL Предикат NULL застосовується спеціально для перевірки, не дорівнює чи перевіряється вираз null-значенням.
Предикат кількісного порівняння:: =
Конструктор значень рядка {= | <|> | <= |> = | <>}
{ANY | SOME | ALL} (Select-вираз)
Квантори ANY і SOME є синонімами і повністю взаємозамінні.
Зауваження. Якщо вказаний один з кванторів ANY і SOME, то предикат кількісного порівняння повертає TRUE, якщо порівнювати значення співпадає хоча б з одним значенням, повернутому у запитів (select-вираженні). Якщо вказаний квантор ALL, то предикат кількісного порівняння повертає TRUE, якщо порівнювати значення співпадає з кожним значенням, повернутому у запитів (select-вираженні).
Предикат EXIST повертає значення TRUE, якщо результат запитів (select-вирази) не порожній.
Предікат unique:: =
UNIQUE (Select-вираз)
Предикат UNIQUE повертає TRUE, якщо в результаті запитів (select-вирази) немає співпадаючих рядків.
Предикат match:: =
Конструктор значень рядка MATCH [UNIQUE]
[PARTIAL | FULL] (Select-вираз)
Предикат MATCH перевіряє, чи буде значення, визначене в конструкторі рядка збігатися зі значенням будь-якого рядка, отриманої в результаті підзапитах.
Предикат overlaps:: =
Конструктор значень рядка OVERLAPS Конструктор значень рядка
Предикат OVERLAPS, є спеціалізованим предикатом, що дозволяє визначити, чи буде вказаний період часу перекривати інший період часу.
Порядок виконання оператора SELECT
Для того щоб зрозуміти, як виходить результат виконання оператора SELECT, розглянемо концептуальну схему його виконання. Ця схема є саме концептуальної, тому що гарантується, що результат буде таким, як якби він виконувався крок за кроком у відповідності з цією схемою. Насправді, реально результат виходить більш витонченими алгоритмами, якими "володіє" конкретна СУБД.
Стадія 1. Виконання одиночного оператора SELECT
Якщо в операторі присутні ключові слова UNION, EXCEPT і INTERSECT, то запит розбивається на кілька незалежних запитів, кожний з яких виконується окремо:
Крок 1 (FROM). Обчислюється пряме декартовій твір всіх таблиць, зазначених в обов'язковому розділі FROM. У результаті кроку 1 отримуємо таблицю A.
Крок 2 (WHERE). Якщо в операторі SELECT присутній розділ WHERE, то сканується таблиці A, отримана на етапі 1. При цьому для кожного рядка з таблиці A обчислюється умовний вираз, наведене в розділі WHERE. Тільки ті рядки, для яких умовний вираз повертає значення TRUE, включаються в результат. Якщо розділ WHERE опущений, то відразу переходимо до кроку 3. Якщо в умовному вираженні беруть участь вкладені вкладені запити, то вони обчислюються відповідно до даної концептуальної схеми. У результаті кроку 2 отримуємо табліцу B.
Крок 3 (GROUP BY). Якщо в операторі SELECT присутній розділ GROUP BY, то рядки таблиці B, отриманої на другому кроці, групуються відповідно до списку угруповання, наведеним у розділі GROUP BY. Якщо розділ GROUP BY опущений, то відразу переходимо до кроку 4. У результаті кроку 3 отримуємо таблиці С.
Крок 4 (HAVING). Якщо в операторі SELECT присутній розділ HAVING, то групи, не задовольняють умовного виразу, наведеному в розділі HAVING, виключаються. Якщо розділ HAVING опущений, то відразу переходимо до кроку 5. У результаті кроку 4 одержуємо табліцу D.
Крок 5 (SELECT). Кожна група, отримана на кроці 4, генерує один рядок результату наступним чином. Обчислюються всі скалярні вирази, зазначені в розділі SELECT. За правилами використання розділу GROUP BY, такі скалярні вирази повинні бути однаковими для всіх рядків усередині кожної групи. Для кожної групи обчислюються значення агрегатних функцій, наведених у розділі SELECT. Якщо розділ GROUP BY був відсутній, але в розділі SELECT є агрегатні функції, то вважається, що є всього одна група. Якщо немає ні розділу GROUP BY, ні агрегатних функцій, то вважається, що є стільки груп, скільки рядків відібрано до даного моменту. У результаті кроку 5 отримуємо табліцу E, містить стільки колонок, скільки елементів наведено в розділі SELECT і стільки рядків, скільки відібрано груп.
Стадія 2. Виконання операцій UNION, EXCEPT, INTERSECT
Якщо в операторі SELECT присутні ключові слова UNION, EXCEPT і INTERSECT, то таблиці, отримані в результаті виконання 1-й стадії, об'єднуються, віднімаються чи перетинаються.
Стадія 3. Впорядкування результату
Якщо в операторі SELECT присутній розділ ORDER BY, то рядки отриманої на попередніх кроках табліци упорядковуються відповідно до списку упорядкування, наведеному в розділі ORDER BY.
Як насправді виконується оператор SELECT
Якщо уважно розглянути наведений вище концептуальний алгоритм обчислення результату оператора SELECT, то відразу зрозуміло, що виконувати його безпосередньо в такому вигляді надзвичайно невигідно. Навіть на першому кроці, коли обчислюється декартово твір таблиць, наведених у розділі FROM, може отримати таблицю величезних розмірів, причому практично більшість рядків і колонок з неї буде відкинуто на наступних кроках.
Насправді в РСУБД є оптимізатор, функцією якого є знаходження такого оптимального алгоритму виконання запиту, який гарантує отримання правильного результату.
Схематично роботу оптимізатора можна представити у вигляді послідовності декількох кроків:
Крок 1 (Синтаксичний аналіз). Надійшов запит піддається синтаксичному аналізу. На цьому кроці визначається, чи правильно взагалі (з точки зору синтаксису SQL) сформульовано запит. У ході синтаксичного аналізу виробляється деякий внутрішньо подання запиту, що використовується на наступних кроках.
Крок 2 (Перетворення в канонічну форму). Запит у внутрішньому поданні піддається перетворенню в деяку канонічну форму. При перетворенні до канонічної формі використовуються як синтаксичні, так і семантичні перетворення. Синтаксичні перетворення (наприклад, приведення логічних виразів до кон'юнктивній або диз'юнктивній нормальній формі, заміна виразів "x AND NOT x" на "FALSE", тощо) дозволяють отримати нове внутрішньо подання запиту, синтаксично еквівалентну вихідного, але стандартне в деякому сенсі . Семантичні перетворення використовують додаткові знання, якими володіє система, наприклад, обмеження цілісності. У результаті семантичних перетворень виходить запит, синтаксично не еквівалентний вихідному, але що дає той же самий результат.
Крок 3 (Генерація планів виконання запиту і вибір оптимального плану). На цьому кроці оптимізатор генерує безліч можливих планів виконання запиту. Кожен план будується як комбінація низькорівневих процедур доступу до даних з таблиць, методам з'єднання таблиць. З усіх згенерованих планів вибирається план, що володіє мінімальною вартістю. При цьому аналізуються дані про наявність індексів у таблиць, статистичних даних про розподіл значень в таблицях, і т.п. Вартість плану це, як правило, сума вартостей виконання окремих низькорівневих процедур, які використовуються для його виконання. У вартість виконання окремої процедури можуть входити оцінки кількості звернень до дисків, ступінь завантаженості процесора і інші параметри.
Крок 4. (Виконання плану запиту). На цьому кроці план, вибраний на попередньому кроці, передається на реальне виконання.
Багато в чому якість конкретної СУБД визначається якістю її оптимізатора. Хороший оптимізатор може підвищити швидкість виконання запиту на кілька порядків. Якість оптимізатора визначається тим, які методи перетворень він може використовувати, який статистичної та іншою інформацією про табліцах він має в своєму розпорядженні, які методи для оцінки вартості виконання плану він знає.
Реалізація реляційної алгебри засобами оператора SELECT (Реляційна повнота SQL)
Для того, щоб показати, що мова SQL є реляційно повним, потрібно показати, що будь-який реляційний оператор може бути виражений засобами SQL. Насправді достатньо показати, що засобами SQL можна виразити будь-який з примітивних реляційних операторів.
Оператор декартового твори
Реляційна алгебра:
Оператор SQL:
SELECT A.Поле1, A.Поле2, ..., B.Поле1, B.Поле2, ...
FROM A, B;
або
SELECT A.Поле1, A.Поле2, ..., B.Поле1, B.Поле2, ...
FROM A CROSS JOIN B;
Оператор проекції
Реляційна алгебра:
Оператор SQL:
SELECT DISTINCT X, Y, ..., Z
FROM A;
Оператор вибірки
Реляційна алгебра: ,
Оператор SQL:
SELECT *
FROM A
WHERE c;
Оператор об'єднання
Реляційна алгебра:
Оператор SQL:
SELECT *
FROM A
UNION
SELECT *
FROM B;
Оператор віднімання
Реляційна алгебра:
Оператор SQL:
SELECT *
FROM A
EXCEPT
SELECT *
FROM B
Реляційний оператор перейменування RENAME висловлюється за допомогою ключового слова AS в списку відбираються полів оператора SELECT. Таким чином, мова SQL є реляційно-повним.
Інші оператори реляційної алгебри (з'єднання, перетин, поділ) виражаються через примітивні, отже, можуть бути виражені операторами SQL. Тим не менш, для практичних цілей наведемо їх.
Оператор з'єднання
Реляційна алгебра:
Оператор SQL:
SELECT A.Поле1, A.Поле2, ..., B.Поле1, B.Поле2, ...
FROM A, B
WHERE c;
або
SELECT A.Поле1, A.Поле2, ..., B.Поле1, B.Поле2, ...
FROM A CROSS JOIN B
WHERE c;
Оператор перетину
Реляційна алгебра:
Оператор SQL:
SELECT *
FROM A
INTERSECT
SELECT *
FROM B;
Оператор розподілу
Реляційна алгебра:
Оператор SQL:
SELECT DISTINCT AX
FROM A
WHERE NOT EXIST
(SELECT *
FROM B
WHERE NOT EXIST
(SELECT *
FROM A A1
WHERE
A1.X = AX AND
A1.Y = BY));
Нехай ставлення A містить дані про постачання деталей, ставлення B містить список всіх деталей, які можуть поставлятися. Атрибут X є номером постачальника, атрибут Y є номером деталі.
Розділити ставлення A на ставлення B означає в даному прикладі "відібрати номери постачальників, які постачають всі деталі".
Перетворимо текст вирази:
"Відібрати номери постачальників, які постачають всі деталі" еквівалентно
"Відібрати ті номери постачальників з таблиці A, для яких не існує непоставляемих деталей в таблиці B" еквівалентно
"Відібрати ті номери постачальників з таблиці A, для яких не існує тих номерів деталей з таблиці B, які не поставляються цим постачальником" еквівалентно
"Відібрати ті номери постачальників з таблиці A, для яких не існує тих номерів деталей з таблиці B, для яких не існує записів про поставки в таблиці A для цього постачальника і цієї деталі".
Останній вираз дослівно перекладається на мову SQL. При перекладі висловлювання на мову SQL потрібно врахувати, що у внутрішньому підзапит таблиця A має бути перейменована, для того щоб відрізняти її від екземпляра цієї ж таблиці, використовуваної в зовнішньому запиті.

Висновок

Фактично стандартною мовою доступу до баз даних в даний час стала мова SQL (Structured Query Language).
Мова SQL оперує термінами, кілька відрізняються від термінів реляційної теорії, наприклад, замість "відносин" використовуються "таблиці", замість "кортежів" - "рядка", замість "атрибутів" - "колонки" або "стовпці".
Стандарт мови SQL, хоча і заснований на реляційній теорії, але в багатьох місцях відходить він неї.
Основу мови SQL складають оператори, умовно розбиті не декілька груп по виконуваних функцій:
Оператори DDL (Data Definition Language) - оператори визначення об'єктів бази даних.
Оператори DML (Data Manipulation Language) - оператори маніпулювання даними.
Оператори захисту і управління даними, та ін
Одним з основних операторів DML є оператор SELECT, що дозволяє витягувати дані з таблиць і отримувати відповіді на різні запити. Оператор SELECT містить у собі всі можливості реляційної алгебри. Це означає, що будь-який оператор реляційної алгебри може бути виражений за допомогою відповідного оператора SELECT. Цим доводиться реляційна повнота мови SQL.
Розрізняють концептуальну схему виконання оператора SELECT і фактичну схему його виконання. Концептуальна схема описує, в якій логічної послідовності повинні виконуватися операції, щоб отримати результат. При реальному виконанні оператора SELECT на перший план виступає досягнення максимальної швидкості виконання запиту. Для цього використовується оптимізатор, який, аналізуючи різні плани виконання запиту, вибирає найкращий з них.

Глосарій

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


Список використаних джерел
1. Дейт К.Дж. Введення в системи баз даних. 6-е вид. - М.: Вільямс. 2000. - 317 с.
2. Коннолі Т., Бегг Л., Страчан А. Бази даних. Проектування, реалізація й супровід. Теорія і практика. 3-є видання. Вільямс 2003. - Таблиці, малюнки. Леонтьєв В.П. ПК: універсальний довідник користувача - М.: 2003. - 251 с.
3. Дейт К. Введення в системи баз даних. 6-е вид. - М.: Вільямс, 2000. - 657с
4. В.В. Фаронов Основи програмування в SQL. - М.: Видавець Молгачева С.В., 2002. - 329 с.
5. Самовчитель по мові SQL (SQL DML) [Електронний ресурс] - Режим доступу http://www.sql-ex.ru/help
6. Конноллі Т., Бегг К., Страчан А. Бази даних. Проектування, реалізація й супровід. Теорія і практика. 2-е вид. - С-Пб.: Вільямс, 2000. - 1120 с.
7. Корнєєв В.В., Гарєєв А.Ф., Васютін С.В., Райх В.В. Бази даних. Інтелектуальна обробка інформації. 2-е вид. - М.: Изд. Молгачева С.В., 2001. - 494 с.
8. Мамаєв Є. Microsoft SQL Server 2000 - СПБ.: БХВ-Петербург, 2002.

9. Когаловскій М.Р. Енциклопедія технологій баз даних. - М.: Фінанси і статистика, 2002.


Додаток А

База даних у сприйнятті користувача

Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Курсова
125.1кб. | скачати


Схожі роботи:
Структура мови
English language for technical colleges
MathML Mathematical Markup Language
Елементи та структура програми мови Паскаль
Системи керовані потоком даних Мова Dataflow Graph Language
SQL Server 2000
Мова запитів SQL
MS SQL Server 1965
Система баз даних MS SQL Server 2000
© Усі права захищені
написати до нас
Рейтинг@Mail.ru